Application = Area:
= DNSSD
NETEXT (Neither agenda nor = minutes received)
Operations & Management = Area:
V6OPS
Routing Area:
= L2VPN
Security Area:
= DICE
Transport Area:
= ALTO
https://da= tatracker.ietf.org/meeting/90/materials.html

Maddy = Conner
IETF Registrar
48377 Fremont Blvd, Ste. 117
Fremont, CA = 94538

Association Management Solutions (AMS)
Forum Management, = Meeting and Event Planning
www.amsl.com
text which is too wide (like emails sent by apple mail to the mailing list archives), you just click the wrap, and the text will be wrapped so it fits the screen... Not sure if that will help with the IESG view, as it might not be the first
 tag on the page, but it works for most of the mailing list
archives etc. 
-- 
kivinen@iki.fi


From nobody Wed Sep 17 07:37:01 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEB71A0428 for ; Wed, 17 Sep 2014 07:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level: 
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham
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 96iJyXmWQx3O for ; Wed, 17 Sep 2014 07:36:43 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 815A51A0154 for ; Wed, 17 Sep 2014 07:36:43 -0700 (PDT)
Received: from unnumerable.local (pool-173-71-50-162.dllstx.fios.verizon.net [173.71.50.162]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8HEagTj012386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Wed, 17 Sep 2014 09:36:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-71-50-162.dllstx.fios.verizon.net [173.71.50.162] claimed to be unnumerable.local
Message-ID: <54199C7A.5010302@nostrum.com>
Date: Wed, 17 Sep 2014 09:36:42 -0500
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: wgchairs@ietf.org
Subject: Re: latest writeup for WG document
References:  <095401cfd1b7$f72a7950$e57f6bf0$@olddog.co.uk> <541845B5.5020909@pi.nu>  <21529.13721.706131.957043@fireball.kivinen.iki.fi>
In-Reply-To: <21529.13721.706131.957043@fireball.kivinen.iki.fi>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/Nwp3f7Bid6DWMWzsJrvr2FCeRYY
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Sep 2014 14:36:54 -0000

That's a very useful trick Tero - thanks!

It does work with the /shepherdwriteup/ page.

RjS

On 9/17/14 2:17 AM, Tero Kivinen wrote:
> Warren Kumari writes:
>> Yup, but when you edit it, please remember to wrap your text at 80ish
>> columns - apparently the view the IESG gets does not auto-wrap (this
>> may be fixed by now) which makes them sad...
> For IESG or other users having similar problems the Wrap bookmarklet
> helps:
>
> javascript:void(document.getElementsByTagName('pre')[0].style.whiteSpace='pre-wrap')
>
>
> I.e. make new bookmark, put name to be something you remember (like
> "Wrap"), copy the javascript above to the Location: and store the
> bookmark somewhere you can easily click it (i.e. bookmarks toolbar or
> similar). Now when you see  text which is too wide (like emails
> sent by apple mail to the mailing list archives), you just click
> the wrap, and the text will be wrapped so it fits the screen... Not
> sure if that will help with the IESG view, as it might not be the
> first  tag on the page, but it works for most of the mailing list
> archives etc.


From nobody Thu Sep 18 09:15:31 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA851A8864; Thu, 18 Sep 2014 09:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 6l7qDRNxiplL; Thu, 18 Sep 2014 09:15:10 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C49B11A8863; Thu, 18 Sep 2014 09:15:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: IETF Agenda 
To: Working Group Chairs 
Subject: REMINDER - 91st IETF - Working Group/BOF/IRTF Scheduling
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p6
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140918161510.26508.19747.idtracker@ietfa.amsl.com>
Date: Thu, 18 Sep 2014 09:15:10 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/Tz1lheK-Jxb3Fn3P64ONtb0mzJU
Cc: irsg@irtf.org
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: IETF Agenda 
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Sep 2014 16:15:20 -0000

-----------------------------------------------------------------
91st IETF – Honolulu, HI, USA
Meeting Dates: November 9 - 14, 2014
-----------------------------------------------------------------

We are accepting scheduling requests for all Working Groups, BOFs, and Research Groups.  

NOTE: Please ensure your list of conflicts is complete and up to date prior to submitting your session request.

The milestones and deadlines for scheduling-related activities are as follows:
Cut-off dates are subject to change.


•	2014-09-26 (Friday): Cut-off date for requests to schedule Working Group meetings at UTC 23:59. To request a Working Group session, use the IETF Meeting Session Request Tool.
•	2014-09-26 (Friday): Cut-off date for BOF proposal requests to Area Directors at UTC 23:59. To request a BOF, please see instructions on Requesting a BOF.
•	2014-10-03 (Friday): Cut-off date for Area Directors to approve BOFs at UTC 23:59.
•	2014-10-10 (Friday): Preliminary agenda published for comment.
•	2014-10-13 (Monday): Cut-off date for requests to reschedule Working Group and BOF meetings UTC 23:59.
•	2014-10-17 (Friday): Final agenda to be published.
•	2014-10-27 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.
•	2014-11-03 (Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.
•	2014-12-05 (Friday): Proceedings submission cutoff date by UTC 23:59, upload using IETF Meeting Materials Management Tool.
•	2014-12-26 (Friday): Proceedings submission corrections cutoff date by UTC 23:59, upload using IETF Meeting Materials Management Tool.


===============================================================
For your convenience, comprehensive information on requesting meeting sessions is presented below:

1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions.  The URL for the tool is:

https://datatracker.ietf.org/secr/sreq/

Instructions for using the tool are available at:

http://www.ietf.org/wg/request-tool-instructions.html

If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org.  If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s).

Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s).

When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line.

2. BOFs will NOT be scheduled unless the Area Director approves the BOF. The proponents behind a BOF need to contact a relevant Area Director, preferably well in advance of the BOF approval deadline date. The AD needs to have the full name of the BOF, its acronym, suggested names of chairs, an agenda, full description of the BOF and the information covered in item 4. Please read RFC 5434 for instructions on how to drive a successful BOF effort. The approval depends on, for instance, Internet-Drafts and list discussion on the suggested topic. BOF agenda requests, if approved, will be submitted to the IETF Secretariat by the ADs.

3. A Working Group may request either one or two sessions.  If your Working Group requires more than two sessions, then your request must be approved by an Area Director.  Additional sessions will be assigned, based on availability, after Monday, October 13th, 2014, the cut-off date for requests to reschedule a session.

4. You MUST provide the following information before a Working Group or BOF session will be scheduled:

a. Working Group or BOF full name with acronym in brackets: 
b. AREA under which Working Group or BOF appears:
c. CONFLICTS you wish to avoid, please be as specific as possible:
d. Expected Attendance:
e. Special requests:
f. Number of sessions:
g. Length of session: 1 hour, 1.5 hours, 2 hours, 2.5 hours
       		
For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt).

===============================================================

Submitting Session Agendas

For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible.  Draft Working Group agendas are due Monday, October 27th, 2014 at UTC 23:59.  Revised Working Group agendas are due no later than Monday, November 3rd, 2014 at UTC 23:59.  The proposed agenda for a BOF session should be submitted along with your request for a session.  Please be sure to copy your Area Director on that message.

Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting.  If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved.

The URL for the tool is:

https://datatracker.ietf.org/secr/proceedings/

Additional information about this tool is available at:

http://www.ietf.org/wg/meeting-materials.html

Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" webpage as soon as they are submitted.

The URL for the "IETF 91 Meeting Materials" Web page is:

https://datatracker.ietf.org/meeting/91/materials.html

If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool."  The same User ID and password will work for both tools.  If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved.  If you require assistance in using either tool, or wish to report a bug, then please send a message to:
ietf-action@ietf.org.

===============================================================
For your convenience please find a list of the IETF Area Directors with their e-mail addresses below:

IETF Chair 
Jari Arkko 

Applications Area (app)
Barry Leiba 
Pete Resnick 

Internet Area (int) 
Brian Haberman  
Ted Lemon 

Operations & Management Area (ops) 
Benoit Claise  
Joel Jaeggli 

Real-time Applications and Infrastructure Area (rai)
Richard Barnes   
Alissa Cooper   

Routing Area (rtg) 
Alia Atlas 
Adrian Farrel   

Security Area (sec) 
Stephen Farrell 
Kathleen Moriarty   

Transport Area (tsv) 
Spencer Dawkins  
Martin Stiemerling  

 ===========================================================
90th IETF Meeting Attendance Numbers

6lo - 66
6tisch - 63
abfab – 42
ace - 70
actn (BoF) - 114
alto  - 38
appsawg/apparea - 157
aqm - 50
avtcore - 49
avtext - 40
bfd - 46
bmwg - 24
ccamp - 42
ccamp (2nd session) - 44
cdni – 35
cfrg - 80
clue – 23
clue (2nd session) - 21
core - 64
core (2nd session) – 31
dane - 158
dart - 57
dclcrg (RG BoF) - 37
dhc - 44
dice - 58
dime - 17
dispatch - 69
dmm - 30
dmm (2nd session) - 28
dnsop - 149
dnssd - 63
dtnwg (BoF) - 85
ecrit - 28
forces - 76
grow - 45
homenet - 136
httpauth - 56
httpbis - Not Provided
httpbis (2nd session) - Not Provided
i2rs - 119
ianaplan - 170
icnrg (RG) - 90
idr - 72
intarea (AG) - 94
ippm - 44
ipsecme - 37
IRTF Open Meeting - 87
isis - 42
jose - 41
kitten - 16
l2vpn - 96
l3vpn - 50
lisp - 24
lmap - 36
lwig - 23
manet - 17
mboned - 16
mif – 49
mile - 32
mmusic - 56
mmusic (2nd session) - 42
mpls - 123
mpls (2nd session) - 68
mptcp - 73
netconf - 94
netext - 26
netmod - 106
nfsv4 - 17
nmrg (RG) - 56
ntp (combined with tictoc) - 30
nvo3 - 102
oauth - 44
opsawg/opsarea - 79
ospf - 42
paws – 23
pce - 87
pim - 21
ppsp - 14
precis - 27
pwe3 - 31
radext - 11
rfcform - 66
rmcat - 52
rmcat (2nd session) - 31
roll - 33
rtcweb - 101
rtcweb (2nd session) - 87
rtgarea (AG) - 150
rtgwg - 64
saag (AG) - 168
sacm - 40
sacm (2nd session) - 29
scim - 28
sdnrg (RG) – 193
sfc - 248
sidr - 60
sipcore - 34
siprec - 11
softwire - 54
spring - 157
stir - 43
straw - 23
sunset4 - 75
taps - 107
tcpinc - 96
tcpm - 46
tictoc (combined with ntp) - 30
tls - 139
tls (2nd session) - 94
tram - 30
trans - 44
trill - 19
tsvwg - 75
tsvwg (2nd session) - 76
ucan (BoF) - 159
uta - 102
urnbis - 29
v6ops - 198
v6ops (2nd session) – 62
vnfpool (BoF) - 180
weirds - 60
xrblock - 25


From nobody Sun Sep 21 23:25:43 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19D61A1A2B for ; Sun, 21 Sep 2014 23:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.787
X-Spam-Level: 
X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham
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 UXAkUpMf_N4T for ; Sun, 21 Sep 2014 23:25:39 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 523041A0352 for ; Sun, 21 Sep 2014 23:25:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1241C2CC64 for ; Mon, 22 Sep 2014 09:25:37 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_i3XKoOTD6y for ; Mon, 22 Sep 2014 09:25:32 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id A59432CC5D for ; Mon, 22 Sep 2014 09:25:32 +0300 (EEST)
From: Jari Arkko 
Content-Type: multipart/signed; boundary="Apple-Mail=_1A1DC22E-1195-4D62-8255-C9CA5025A55E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Subject: WG scheduling and BOF proposals due Friday
Message-Id: <94A8C350-242C-45B6-AA1C-DC12375531B9@piuha.net>
Date: Mon, 22 Sep 2014 09:25:31 +0300
To: IETF WG Chairs 
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/lA4pfmlSGq0zpHjF2Tdbeb6haw4
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 06:25:41 -0000

--Apple-Mail=_1A1DC22E-1195-4D62-8255-C9CA5025A55E
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

A reminder: http://www.ietf.org/blog/2014/09/hawaii-bof-proposals-due-soon/

Jari


--Apple-Mail=_1A1DC22E-1195-4D62-8255-C9CA5025A55E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUH8DbAAoJEM80gCTQU46qtasP/RrZ1fuLFRHcSpN73K6LwUxk
BbVLjZCI7tpoDLYu/5bA/MnDIMIftgT7Q8z4sok6VG23/0EkyWoVdsL518rngrPl
ialB14eN+jmn0OFudqTMhJdtIAIHuC0H9b3hpcfZAHM8L09vIeX8HqPqeKGsYhCR
PcnMyYt8ISprqymRH3EcKYnra1nfvFqEgwASnsOGesvOHA31HfndlO2kEM3CN0EZ
hzbN2GQik4cjWVshiJ17gpvXVhxUSaLTKupsqTL1t7Syv/qOJ2a5C3uNK8ZPAKII
LgSJA9zXYpuqQITUdLYIy7J1Go7Tqz+M++3YV82j97JCsnE2CXkyxXvBoFIeJH+r
+6Y7AMHf76m1xCWjQKY9O1J8A/Cgz8R0N4oDjRUYbS/0g9DXk2Z5r0KKZ7emYJh1
M7cXmaYkSBrZkdnaK6LzBc5ees3QGvDG9l1Uv4MrktHfs6loaoL0dST0VDsx9Ms6
qx7/JfGewfwFPXaAjwqtNH/zNyJMSHuyy8KFbxHdsWKqWsIm1X4FQdfMqsSG64gA
wXRnorOun5qf0PJk/x1acb8zxo9q+UH9nX12f85yrEBlSchUKU+Va/p4VGD1Io6u
6QjGRcvEqqVmYRzUAdvyTRfWfwUVNa/hRCvBsX6YZK3NQmRP1YKmjHdHPxLY45wT
SCXe4/VXd1XgzFvkVkmU
=UsnZ
-----END PGP SIGNATURE-----

--Apple-Mail=_1A1DC22E-1195-4D62-8255-C9CA5025A55E--


From nobody Mon Sep 22 06:59:29 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828E61A1AC2 for ; Mon, 22 Sep 2014 06:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.787
X-Spam-Level: 
X-Spam-Status: No, score=-7.787 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 W5etyacC4l0O for ; Mon, 22 Sep 2014 06:59:04 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC741A1B51 for ; Mon, 22 Sep 2014 06:41:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411393315; x=1442929315; h=message-id:date:from:mime-version:to:subject:sender: content-transfer-encoding; bh=DLmo6PmN7KrH5Yf69x2OQ1sJIkufsyFyWs/W65V0BLg=; b=hFXeD+Vcv8riz/8UFhVxiFgCjqx/nFTCsGoNrvZe8xB+wkq2BzoSbxDM mHSC3RG1ALYVFeUsmuYs49iTIqhl2b78s9QRQXt2CRGFh3OjLsOK8zV9q 4iAnBNsdpf0+vPAZ1VViljeQdvWa4a/FouViyHXehs5EtI2LAoUzUj+MK 8=;
X-IronPort-AV: E=McAfee;i="5600,1067,7568"; a="75245349"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Sep 2014 06:41:47 -0700
X-IronPort-AV: E=Sophos;i="5.04,571,1406617200"; d="scan'208";a="809946799"
Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Sep 2014 06:41:47 -0700
Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 22 Sep 2014 06:41:46 -0700
Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 22 Sep 2014 06:41:46 -0700
Message-ID: <54202706.7030501@qti.qualcomm.com>
Date: Mon, 22 Sep 2014 08:41:26 -0500
From: Pete Resnick , Spencer Dawkins 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: WG Chairs 
Subject: Meeting room layout experiment at IETF 92 in Dallas
Sender: Pete Resnick 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.46.201.191) To NASANEXM01F.na.qualcomm.com (10.46.201.192)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/cY6cZtKrJ73PWLGus8DBZ40laYs
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 13:59:06 -0000

Lars Eggert, IRTF Chair, has been talking with the research group chairs 
about ways to make their meetings more effective, and one topic that 
came up, is that when some of the research groups meet in one of the 
smaller "round table" conference rooms, they tend to have discussions, 
and when they meet in one of the IETF working group meeting rooms, they 
tend to have presentations with a few people asking questions, and 
almost no discussion. At least a couple of the research group chairs 
have asked to meet in "round table configurations".

The IESG would like to find out whether there are IETF working groups 
that would like to experiment with similar room configurations during 
IETF 92 in Dallas.

We recognize that the constraints on IETF working groups aren't the same 
as for IRTF research groups. BCP 25, "IETF Working Group Guidelines and 
Procedures", says "participation is open to all", so we would need to 
ensure that working group participants aren't excluded simply because 
room size, and that remote participants are supported at least as well 
as today. That likely translates into a meeting room about the size 
working groups typically usually use today, but with a large conference 
table surrounded by chairs, plus additional rows of chairs around it to 
accommodate everyone, with additional microphones around the table, and 
mics elsewhere in the room available to everyone, etc. (The ISOC 
Advisory Council meetings that meet on the Friday of IETF week use a 
similar setup, if you have ever attended one of their meetings.)

But before we ask folks who are skilled in the art to figure out (for 
instance) what Meetecho could do for remote participants in a room 
configuration like this, we want to ask working group chairs if you 
would like to participate in an experiment with your working group(s), 
at IETF 92 in Dallas.

Pete & Spencer, for the IESG


From nobody Mon Sep 22 09:53:01 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D2C1A0203 for ; Mon, 22 Sep 2014 09:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 uW_3VDKKKkX6 for ; Mon, 22 Sep 2014 09:52:56 -0700 (PDT)
Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002951A1B37 for ; Mon, 22 Sep 2014 09:52:55 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id 0A1472261 for ; Mon, 22 Sep 2014 12:52:55 -0400 (EDT)
Received: from web1 ([10.202.2.211]) by compute5.internal (MEProxy); Mon, 22 Sep 2014 12:52:55 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:reply-to:date :in-reply-to:references; s=smtpout; bh=Ik4kUYaP5sxdXJpQMouqN14bO ag=; b=dgr9t6J+vjbhQQp6rNEjFLfkawy+Z0uvrTm/2UKbVDQuqZi754yy4B2mG p/kw31LacU20y50O1m/7heq0DMe0eWvdlqHQsQ6ofeVp9MZJRgpe5G+Zh+m/HNXn yrduQY5pCKZNiRlQd4ZzjhqO0LLxK/8KV0kB7D/0JSMFYto/bU=
Received: by web1.nyi.internal (Postfix, from userid 99) id A0717F008DE; Mon, 22 Sep 2014 12:52:54 -0400 (EDT)
Message-Id: <1411404774.4139109.170399049.025C838D@webmail.messagingengine.com>
X-Sasl-Enc: DrDOnWP5QoeyfRG4mSGshRehRHkGkNS6An/9vWpH6Iy7 1411404774
From: Bill Cerveny 
To: wgchairs@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
X-Mailer: MessagingEngine.com Webmail Interface - ajax-b5aef30d
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
Date: Mon, 22 Sep 2014 12:52:54 -0400
In-Reply-To: <54202706.7030501@qti.qualcomm.com>
References: <54202706.7030501@qti.qualcomm.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/TKo8aczzVetR1ntx-hgiKDvO-BQ
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: bill@wjcerveny.com
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 16:52:58 -0000

Clarifying question ... how large of a table or round table setup are we
talking about (how many seats or chairs)? My initial, perhaps obvious,
impression is that if the number of seats at a round table setup is
greater than the number of people who typically speak at a meeting with
the "old" format, it could be a win. It'd be an even bigger win if
everyone in a smaller working group meeting could be seated at the round
table. However, I'm not sure if there'd be a difference in participation
if the number of seats at the round table is less than the number who
typically participate.

Thanks,

Bill Cerveny

On Mon, Sep 22, 2014, at 09:41 AM, Pete Resnick wrote:
> Lars Eggert, IRTF Chair, has been talking with the research group chairs 
> about ways to make their meetings more effective, and one topic that 
> came up, is that when some of the research groups meet in one of the 
> smaller "round table" conference rooms, they tend to have discussions, 
> and when they meet in one of the IETF working group meeting rooms, they 
> tend to have presentations with a few people asking questions, and 
> almost no discussion. At least a couple of the research group chairs 
> have asked to meet in "round table configurations".
> 
> The IESG would like to find out whether there are IETF working groups 
> that would like to experiment with similar room configurations during 
> IETF 92 in Dallas.
> 
> We recognize that the constraints on IETF working groups aren't the same 
> as for IRTF research groups. BCP 25, "IETF Working Group Guidelines and 
> Procedures", says "participation is open to all", so we would need to 
> ensure that working group participants aren't excluded simply because 
> room size, and that remote participants are supported at least as well 
> as today. That likely translates into a meeting room about the size 
> working groups typically usually use today, but with a large conference 
> table surrounded by chairs, plus additional rows of chairs around it to 
> accommodate everyone, with additional microphones around the table, and 
> mics elsewhere in the room available to everyone, etc. (The ISOC 
> Advisory Council meetings that meet on the Friday of IETF week use a 
> similar setup, if you have ever attended one of their meetings.)
> 
> But before we ask folks who are skilled in the art to figure out (for 
> instance) what Meetecho could do for remote participants in a room 
> configuration like this, we want to ask working group chairs if you 
> would like to participate in an experiment with your working group(s), 
> at IETF 92 in Dallas.
> 
> Pete & Spencer, for the IESG
> 


From nobody Mon Sep 22 09:56:02 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106D11A1B56 for ; Mon, 22 Sep 2014 09:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 yP_gBsu8WHuc for ; Mon, 22 Sep 2014 09:55:58 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7BA1A1B51 for ; Mon, 22 Sep 2014 09:55:58 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id fb4so3337078wid.1 for ; Mon, 22 Sep 2014 09:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tQiPjIwbxeDfsvLQEw8/JI34hp6wdA2qbXZppcE0TF4=; b=x8rl1xlf47ozKnW7dkJbR3LIbQjQBbNyWaImIhAFfjgZOD4ieq7I0DfvDD1VojufSn 3R1JLX+ir1fx03O3fmUFWc38NJdSqffA+SMu1E2V0q55NN/DDDh98Z93coVriJ5CVFQi dN7iRmBrKUcWw6CFM1HBzp/hfkMNRG8/9yeBQJEbH6iu2jThKLS7sRCsUmC8z5T0LaDJ /0OpwijuTPjYxc5iJVXDUO2Vyjefou9OodIVBlnjUEob2UV2Ij5AW7K0fxgi0Hpq2kzr 9UOnrpcXHumGQpAXZLqEVrWzlssEWp/Pqs9Ejse6QVHym3K6j7WZjdRO4hTnYW+iAsuX a0cg==
X-Received: by 10.194.83.6 with SMTP id m6mr4467220wjy.90.1411404957069; Mon, 22 Sep 2014 09:55:57 -0700 (PDT)
Received: from [10.0.0.4] ([109.66.16.60]) by mx.google.com with ESMTPSA id bt9sm12900099wjc.44.2014.09.22.09.55.56 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Sep 2014 09:55:56 -0700 (PDT)
Message-ID: <54205496.9050503@gmail.com>
Date: Mon, 22 Sep 2014 19:55:50 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Pete Resnick ,  Spencer Dawkins , WG Chairs 
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
References: <54202706.7030501@qti.qualcomm.com>
In-Reply-To: <54202706.7030501@qti.qualcomm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/B1jqI9o4S2Rz0iy_f2p1lJ8mfa0
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 16:56:00 -0000

Hi Pete,

Over the last few years, I have mostly participated remotely, so my 
interest is somewhat academic. Having said that, IMHO this is not a good 
idea, at least for my WG.

Like most working groups, we have the active participants and the 
tourists. A central table can easily accommodate the regular 
participants but the current proposal ("additional rows of chairs around 
[the table] to accommodate everyone") will have most of the non-regulars 
in the back of the room, effectively excluded from the discussion.

I think it is our job to encourage the non-regulars to participate, and 
this idea would run counter to that.

Thanks,
	Yaron

On 09/22/2014 04:41 PM, Pete Resnick wrote:
> Lars Eggert, IRTF Chair, has been talking with the research group chairs
> about ways to make their meetings more effective, and one topic that
> came up, is that when some of the research groups meet in one of the
> smaller "round table" conference rooms, they tend to have discussions,
> and when they meet in one of the IETF working group meeting rooms, they
> tend to have presentations with a few people asking questions, and
> almost no discussion. At least a couple of the research group chairs
> have asked to meet in "round table configurations".
>
> The IESG would like to find out whether there are IETF working groups
> that would like to experiment with similar room configurations during
> IETF 92 in Dallas.
>
> We recognize that the constraints on IETF working groups aren't the same
> as for IRTF research groups. BCP 25, "IETF Working Group Guidelines and
> Procedures", says "participation is open to all", so we would need to
> ensure that working group participants aren't excluded simply because
> room size, and that remote participants are supported at least as well
> as today. That likely translates into a meeting room about the size
> working groups typically usually use today, but with a large conference
> table surrounded by chairs, plus additional rows of chairs around it to
> accommodate everyone, with additional microphones around the table, and
> mics elsewhere in the room available to everyone, etc. (The ISOC
> Advisory Council meetings that meet on the Friday of IETF week use a
> similar setup, if you have ever attended one of their meetings.)
>
> But before we ask folks who are skilled in the art to figure out (for
> instance) what Meetecho could do for remote participants in a room
> configuration like this, we want to ask working group chairs if you
> would like to participate in an experiment with your working group(s),
> at IETF 92 in Dallas.
>
> Pete & Spencer, for the IESG
>


From nobody Mon Sep 22 09:59:50 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B657E1A1B5A for ; Mon, 22 Sep 2014 09:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.787
X-Spam-Level: 
X-Spam-Status: No, score=-7.787 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 AG3IgD4Y8CWd for ; Mon, 22 Sep 2014 09:59:35 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974161A012D for ; Mon, 22 Sep 2014 09:59:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411405175; x=1442941175; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yvDOQyg1o1aEON4Hg4fLtXriHq+JdSBPHLc32Ojjjn8=; b=MrKDyApeTQ2JqURfe44Rr5MbAIlnTbR/ZxA1+ldf7UMNtLh2QHLO0sZP eg8I+yymI4CXNdxnZfGCOFMUZ8NPzcWQrNwXKQ4l98JN5ezoJBL8nolvZ PNyOFpaKHDl8aSKv2djYnL7SV6mtoZX+XgqHkb2aJzodpjQvLKmZbsOwd g=;
X-IronPort-AV: E=McAfee;i="5600,1067,7569"; a="74644380"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Sep 2014 09:59:35 -0700
X-IronPort-AV: E=Sophos;i="5.04,572,1406617200"; d="scan'208";a="715687979"
Received: from nasanexhc03.na.qualcomm.com ([10.46.200.142]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Sep 2014 09:59:35 -0700
Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by NASANEXHC03.na.qualcomm.com (10.46.200.142) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 22 Sep 2014 09:59:34 -0700
Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 22 Sep 2014 09:59:33 -0700
Message-ID: <54205573.3050301@qti.qualcomm.com>
Date: Mon, 22 Sep 2014 11:59:31 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: 
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
References: <54202706.7030501@qti.qualcomm.com> <1411404774.4139109.170399049.025C838D@webmail.messagingengine.com>
In-Reply-To: <1411404774.4139109.170399049.025C838D@webmail.messagingengine.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.46.201.192) To NASANEXM01F.na.qualcomm.com (10.46.201.192)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/Yj0rRWoo2duRXEpUJG_g2cVWeyw
Cc: wgchairs@ietf.org
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 16:59:46 -0000

On 9/22/14 11:52 AM, Bill Cerveny wrote:
> Clarifying question ... how large of a table or round table setup are we
> talking about (how many seats or chairs)? My initial, perhaps obvious,
> impression is that if the number of seats at a round table setup is
> greater than the number of people who typically speak at a meeting with
> the "old" format, it could be a win. It'd be an even bigger win if
> everyone in a smaller working group meeting could be seated at the round
> table. However, I'm not sure if there'd be a difference in participation
> if the number of seats at the round table is less than the number who
> typically participate.
>    

I think we definitely envisioned that the table would be large enough to 
hold at a minimum the number of folks that normally speak, and hopefully 
more. If I had to divine logistics, I'd guess that when you put in your 
meeting request, you'd say that you wanted the round (well, really an 
open square in all likelihood) table format, and indicate how many you 
want at the table and how many additional seats you'd want.

pr

-- 
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478


From nobody Mon Sep 22 10:21:13 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C441A1BB6 for ; Mon, 22 Sep 2014 10:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.787
X-Spam-Level: 
X-Spam-Status: No, score=-7.787 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 AfxNXkWeWXKK for ; Mon, 22 Sep 2014 10:21:09 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4401A1B6C for ; Mon, 22 Sep 2014 10:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411406469; x=1442942469; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nixb8kw53Gw/uUKS60keXHgCbUraR++kXPvKbsR4VGo=; b=IzVzQ/S1JoW1B2tCadSNUCsvWRdh+rs1ftzHzTx5Iaw4Pbwt6rjCg8R5 COqCd8Ja+0ds1fsa3MkiRVxmpdEpFejV19617ESFQtBUFdu4rhplp32pt FG4Ceea/6GNowC6rMsWFbE8x+Zu02yFiyhszcBn3hlDYMH4W7nA3NPfSk g=;
X-IronPort-AV: E=McAfee;i="5600,1067,7569"; a="160484711"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Sep 2014 10:21:08 -0700
X-IronPort-AV: E=Sophos;i="5.04,572,1406617200"; d="scan'208";a="755719124"
Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Sep 2014 10:21:08 -0700
Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 22 Sep 2014 10:21:08 -0700
Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 22 Sep 2014 10:20:55 -0700
Message-ID: <54205A75.8090808@qti.qualcomm.com>
Date: Mon, 22 Sep 2014 12:20:53 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Yaron Sheffer 
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
References: <54202706.7030501@qti.qualcomm.com> <54205496.9050503@gmail.com>
In-Reply-To: <54205496.9050503@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.46.201.192) To NASANEXM01F.na.qualcomm.com (10.46.201.192)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/iR_mLaGhQwOyhGcewDRdQVJ1Rlk
Cc: WG Chairs , Spencer Dawkins 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 17:21:11 -0000

On 9/22/14 11:55 AM, Yaron Sheffer wrote:
> Hi Pete,
>
> Over the last few years, I have mostly participated remotely, so my 
> interest is somewhat academic. Having said that, IMHO this is not a 
> good idea, at least for my WG.
>
> Like most working groups, we have the active participants and the 
> tourists. A central table can easily accommodate the regular 
> participants but the current proposal ("additional rows of chairs 
> around [the table] to accommodate everyone") will have most of the 
> non-regulars in the back of the room, effectively excluded from the 
> discussion.

For some WG's, we'll be able to get everyone around the table. For 
others, perhaps set up like the ISOC AC meetings, you'll have three 
sides of the table have just a few rows each of chairs set up behind 
those sitting at the table, so it's not like the "back of the room" is 
all that far back. And you'll note that below we mentioned "mics 
elsewhere in the room available to everyone"; the expectation is that 
anyone in the room could get up to a mic and speak. I don't think that's 
"effectively excluded". But I don't want to dismiss your point: I agree 
that it does change the dynamic, and folks at the table (and perhaps the 
immediate row behind) are much more likely to feel comfortable 
participating than folks further back. That said:

> I think it is our job to encourage the non-regulars to participate, 
> and this idea would run counter to that.

While I think it is *a* job of the chair to encourage non-regulars to 
participate, it's certainly not the *primary* job. Getting productive 
work done is. Making it seem more open to non-regulars *at the expense 
of* productivity is probably not a great idea either. The reason for 
this experiment is because we've heard that there are WGs where it would 
help productivity to move away from the lecture/Q&A style format to a 
more round-table discussion format. I've certainly chaired WGs where we 
could get everyone (participants and just observers) around a single 
table, and others that could be accommodated with just a couple of rows 
of additional seating, and could have benefited tremendously from 
getting rid of the "presentation format". Perhaps there are WGs where 
this doesn't make sense at all. But this is why we expect this to be the 
choice of the chair and the WG. The question is whether anyone of you 
would like to give it a shot.

pr

> On 09/22/2014 04:41 PM, Pete Resnick wrote:
>> Lars Eggert, IRTF Chair, has been talking with the research group chairs
>> about ways to make their meetings more effective, and one topic that
>> came up, is that when some of the research groups meet in one of the
>> smaller "round table" conference rooms, they tend to have discussions,
>> and when they meet in one of the IETF working group meeting rooms, they
>> tend to have presentations with a few people asking questions, and
>> almost no discussion. At least a couple of the research group chairs
>> have asked to meet in "round table configurations".
>>
>> The IESG would like to find out whether there are IETF working groups
>> that would like to experiment with similar room configurations during
>> IETF 92 in Dallas.
>>
>> We recognize that the constraints on IETF working groups aren't the same
>> as for IRTF research groups. BCP 25, "IETF Working Group Guidelines and
>> Procedures", says "participation is open to all", so we would need to
>> ensure that working group participants aren't excluded simply because
>> room size, and that remote participants are supported at least as well
>> as today. That likely translates into a meeting room about the size
>> working groups typically usually use today, but with a large conference
>> table surrounded by chairs, plus additional rows of chairs around it to
>> accommodate everyone, with additional microphones around the table, and
>> mics elsewhere in the room available to everyone, etc. (The ISOC
>> Advisory Council meetings that meet on the Friday of IETF week use a
>> similar setup, if you have ever attended one of their meetings.)
>>
>> But before we ask folks who are skilled in the art to figure out (for
>> instance) what Meetecho could do for remote participants in a room
>> configuration like this, we want to ask working group chairs if you
>> would like to participate in an experiment with your working group(s),
>> at IETF 92 in Dallas.
>>
>> Pete & Spencer, for the IESG
>>
>

-- 
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478


From nobody Mon Sep 22 10:36:00 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC0F1A1BCB for ; Mon, 22 Sep 2014 10:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 GE5x6MSywNOO for ; Mon, 22 Sep 2014 10:35:52 -0700 (PDT)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4711A1BC8 for ; Mon, 22 Sep 2014 10:35:52 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id v10so3729893pde.6 for ; Mon, 22 Sep 2014 10:35:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QndxdZvE+g64duh2gDnSGjL3QJ8vD6SB2BBZj/7+fRE=; b=OVwNwT8kn6/BTrSx3/yXy91Vgvg2aAiG3/vrpnfeAdDzINniMoySHUzDJaZuJ4NbPb I3BLqEPrC5JEjWLCaXRsIE5CWNpSQeTGnSalJPldlDEG2W5zKOIZTcW9EoHGrE1Bjrmr 9IzTXDqYNzOL0ibXKEE+7hg31EHnoXDUUxdGeaB7WtH5WH2NIWfaDSmURV2Mf+1+0xjH cEWCdn6IDo6dqdZc42o+mBEvuATGMcAHrtW5IUJXdOJPJuBQhIX4X8SgYvyK9StJSmnH MOiWTWIGjcWebIbyyZ2E8gXknowfPR28SmrFTUM2PGQTUuDGG8YbxWOji2psawjFcHJq z1FQ==
X-Received: by 10.66.163.65 with SMTP id yg1mr28444824pab.33.1411407352377; Mon, 22 Sep 2014 10:35:52 -0700 (PDT)
Received: from spandex.local (63-140-99-216.dynamic.dsl.acsalaska.net. [63.140.99.216]) by mx.google.com with ESMTPSA id cw5sm9898439pbc.9.2014.09.22.10.35.51 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Sep 2014 10:35:51 -0700 (PDT)
Message-ID: <54205DF5.3010603@gmail.com>
Date: Mon, 22 Sep 2014 09:35:49 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: wgchairs@ietf.org
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
References: <54202706.7030501@qti.qualcomm.com> <54205496.9050503@gmail.com> <54205A75.8090808@qti.qualcomm.com>
In-Reply-To: <54205A75.8090808@qti.qualcomm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/nZXztWRXUbMm0AaxQyo29Qirsos
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 17:35:56 -0000

On 9/22/14 9:20 AM, Pete Resnick wrote:
> The question is whether anyone of you would like to give it a shot.

I think we're probably interested.  I think it's a good idea.  Getting
back to the productivity question, I tend to think that presentations
are often (but not always) a complete waste of valuable meeting time and
that we need to be better about finding ways to facilitate discussion.
It also seems to me that a more (for the lack of a better word)
egalitarian room layout might help working group participants who
don't have the editor token for a document feel more directly involved.
I can also see where thing could become chaotic in those situations
where there's strong disagreement and not a lot of self-restraint.
Worth a shot in any event, and I do tend to think that it could lead to
a more productive use of meeting time.

Melinda


From nobody Mon Sep 22 10:38:30 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91D81A1B92 for ; Mon, 22 Sep 2014 10:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
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 7Q0pPedHpYIj for ; Mon, 22 Sep 2014 10:38:26 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B63F1A1B6A for ; Mon, 22 Sep 2014 10:38:26 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 17BACE00D; Mon, 22 Sep 2014 13:43:36 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 99C7163AE9; Mon, 22 Sep 2014 13:38:25 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7EC5D63AD5; Mon, 22 Sep 2014 13:38:25 -0400 (EDT)
From: Michael Richardson 
To: Pete Resnick , Spencer Dawkins 
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
In-Reply-To: <54202706.7030501@qti.qualcomm.com>
References: <54202706.7030501@qti.qualcomm.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.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
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/WRstpkcfSqSwWBmSwLYXue5BNQs
Cc: WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 17:38:27 -0000

--=-=-=


Pete Resnick , wrote:
    > translates into a meeting room about the size working groups typically
    > usually use today, but with a large conference table surrounded by
    > chairs,

Do you mean a single table, or a square of tables, with an empty space in the
middle?

Thank you for doing this experiment.
(my WG is not meeting, so it's moot point)

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVCBej4CLcPvd0N1lAQJ1Ogf/Uv6c/a04i3tbqAEg64Ka9gnmB8urF92+
Msh4gZzpkkp4UGm/GHJiqdE8ME++/z7yLJw4iaJikwuTykDWHrn7p7mQVIg08NKn
IWfNT9XyI0gJDHvFf5ntaGZEz7Wo81NmNYNU0qusUOXPUO2aMZQGpvls23iSsatM
e6ovAGSiy4KBR53ec4/ve1pYXkwtljJAaDrQf812gYqyJMVnmQE+gXvp0jJPUd7I
S4nqBJYg/AANmcAMTFvKyzDU2nBZ6wkgcDbrkTIL94E1FqH8a4z+YZwXre6JqycL
CHokW43kvp00dwQEWdLqWDsQmndmEHjdXHwbz5TYurSeTa6kp3OGqA==
=pXRL
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Sep 22 10:45:19 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D211A1BE5 for ; Mon, 22 Sep 2014 10:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 p8mcfhG6j5FM for ; Mon, 22 Sep 2014 10:45:15 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5637A1A1B27 for ; Mon, 22 Sep 2014 10:45:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1167; q=dns/txt; s=iport; t=1411407913; x=1412617513; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TIVV0H5I/aadE0wnWbg9JQ2gPw7OFFvkmimPUZVe1bc=; b=YgpySEikgy5nw3EBx5rvphwJZg2Lp64y8DJLe2aXbZawqqoI7HR06FAy bQ+/MPetdJgjCd8nTSJ4tz1GiOHSm4uGGq/WUnSDhleH4egdj9Ef6kxC6 GwTD9Z37Nh4H+SywCnr04l4c/bfIKDA1xNABJxwRLf1lfYNXi8gseK0Ic w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAP5eIFStJA2I/2dsb2JhbABggw6BKgTSHAGBDhYBeoQEAQEEOk8CAQgYHhAhESUCBAESiCoDEb0+DYZ8AReNV4I2hEsBBJFXiS+CEI8NhkWDYWyBSIECAQEB
X-IronPort-AV: E=Sophos;i="5.04,572,1406592000"; d="scan'208";a="357238875"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP; 22 Sep 2014 17:45:12 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8MHjCL3019061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 17:45:12 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 12:45:12 -0500
From: "Morteza Ansari (moransar)" 
To: Melinda Shore , "wgchairs@ietf.org" 
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
Thread-Topic: Meeting room layout experiment at IETF 92 in Dallas
Thread-Index: AQHP1m1/7Rchwm/nrk6e1gXKE4JYq5wNsxYAgAAHAICAAAQsgP//jUWA
Date: Mon, 22 Sep 2014 17:45:11 +0000
Message-ID: 
References: <54202706.7030501@qti.qualcomm.com> <54205496.9050503@gmail.com> <54205A75.8090808@qti.qualcomm.com> <54205DF5.3010603@gmail.com>
In-Reply-To: <54205DF5.3010603@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [10.21.78.186]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7BCA51C760BDAE40AFF183D76DC7CCD6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/w0FUyZGddShGGzTI5QzFwG1R67w
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 17:45:17 -0000

+1  I totally agree with what Melinda said maybe with the exception of the
last bit. Not sure how room arrangement would make things more chaotic in
case of strong disagreement.


Cheers,
Morteza

On 9/22/14, 10:35 AM, "Melinda Shore"  wrote:

>On 9/22/14 9:20 AM, Pete Resnick wrote:
>> The question is whether anyone of you would like to give it a shot.
>
>I think we're probably interested.  I think it's a good idea.  Getting
>back to the productivity question, I tend to think that presentations
>are often (but not always) a complete waste of valuable meeting time and
>that we need to be better about finding ways to facilitate discussion.
>It also seems to me that a more (for the lack of a better word)
>egalitarian room layout might help working group participants who
>don't have the editor token for a document feel more directly involved.
>I can also see where thing could become chaotic in those situations
>where there's strong disagreement and not a lot of self-restraint.
>Worth a shot in any event, and I do tend to think that it could lead to
>a more productive use of meeting time.
>
>Melinda
>


From nobody Mon Sep 22 11:43:30 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A531A1AF4 for ; Mon, 22 Sep 2014 11:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 1YWBf1Y1WMhb for ; Mon, 22 Sep 2014 11:43:25 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F111A1A1B0D for ; Mon, 22 Sep 2014 11:43:24 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id ty20so7227028lab.7 for ; Mon, 22 Sep 2014 11:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+TSmAgh1qENcCygbqopnSzfLJA+CRmTSYCvVLRToA2E=; b=VZGJxTjRq9EDM4MVZIuxgMANKU8O3r4tfH5MVh2kJWf5+tHn99IOaf3DL9/iRIdehQ JvvOysZNzg39bIYxFtZZuuw+DRVJqaC5oRvcbK5eYN8YFymEm2J+pDkZ3T9btOd3IybS ZvRiBBQIfGAM00lGvv7+ZDfHUudIHUlSRIjsLy3W4drnr60WjkhFCSWLSdjXezjwB9S/ RGme0gOM5k6C47XOjLFvKKb86iAJgr5q594xBFrjzjcR5+mbvvOaAVJqNmmyyoO+TDBO bDUvgaZ9pTIWu3kuIWwQw1nGuxVH3FWSXmnCc16dnBPZwwSiHosECrRObcHqcH1HDDqL K5Yw==
MIME-Version: 1.0
X-Received: by 10.152.36.134 with SMTP id q6mr27862887laj.35.1411411403270; Mon, 22 Sep 2014 11:43:23 -0700 (PDT)
Received: by 10.25.12.207 with HTTP; Mon, 22 Sep 2014 11:43:23 -0700 (PDT)
In-Reply-To: <54205496.9050503@gmail.com>
References: <54202706.7030501@qti.qualcomm.com> <54205496.9050503@gmail.com>
Date: Mon, 22 Sep 2014 13:43:23 -0500
Message-ID: 
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
From: Mary Barnes 
To: Yaron Sheffer 
Content-Type: multipart/alternative; boundary=047d7b5d91ef52ef070503abd3bb
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/7H585LQTeaFYGyZTl87ViwUavgQ
Cc: WG Chairs , Pete Resnick , Spencer Dawkins 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 18:43:27 -0000

--047d7b5d91ef52ef070503abd3bb
Content-Type: text/plain; charset=UTF-8

I think it depends upon the size of the WG.  I personally think this could
be quite effective for WGs with 30 or less participants (including
tourists).  I think a horseshoe layout can work for a group that size.
Although I personally like the idea of having a horseshoe for 12-18 and
having people, that are there just to have a table to put their computer to
type or read email, sit in classroom style seating behind the horseshoe.

Mary.

On Mon, Sep 22, 2014 at 11:55 AM, Yaron Sheffer 
wrote:

> Hi Pete,
>
> Over the last few years, I have mostly participated remotely, so my
> interest is somewhat academic. Having said that, IMHO this is not a good
> idea, at least for my WG.
>
> Like most working groups, we have the active participants and the
> tourists. A central table can easily accommodate the regular participants
> but the current proposal ("additional rows of chairs around [the table] to
> accommodate everyone") will have most of the non-regulars in the back of
> the room, effectively excluded from the discussion.
>
> I think it is our job to encourage the non-regulars to participate, and
> this idea would run counter to that.
>
> Thanks,
>         Yaron
>
>
> On 09/22/2014 04:41 PM, Pete Resnick wrote:
>
>> Lars Eggert, IRTF Chair, has been talking with the research group chairs
>> about ways to make their meetings more effective, and one topic that
>> came up, is that when some of the research groups meet in one of the
>> smaller "round table" conference rooms, they tend to have discussions,
>> and when they meet in one of the IETF working group meeting rooms, they
>> tend to have presentations with a few people asking questions, and
>> almost no discussion. At least a couple of the research group chairs
>> have asked to meet in "round table configurations".
>>
>> The IESG would like to find out whether there are IETF working groups
>> that would like to experiment with similar room configurations during
>> IETF 92 in Dallas.
>>
>> We recognize that the constraints on IETF working groups aren't the same
>> as for IRTF research groups. BCP 25, "IETF Working Group Guidelines and
>> Procedures", says "participation is open to all", so we would need to
>> ensure that working group participants aren't excluded simply because
>> room size, and that remote participants are supported at least as well
>> as today. That likely translates into a meeting room about the size
>> working groups typically usually use today, but with a large conference
>> table surrounded by chairs, plus additional rows of chairs around it to
>> accommodate everyone, with additional microphones around the table, and
>> mics elsewhere in the room available to everyone, etc. (The ISOC
>> Advisory Council meetings that meet on the Friday of IETF week use a
>> similar setup, if you have ever attended one of their meetings.)
>>
>> But before we ask folks who are skilled in the art to figure out (for
>> instance) what Meetecho could do for remote participants in a room
>> configuration like this, we want to ask working group chairs if you
>> would like to participate in an experiment with your working group(s),
>> at IETF 92 in Dallas.
>>
>> Pete & Spencer, for the IESG
>>
>>
>

--047d7b5d91ef52ef070503abd3bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think it depends upon the size of the WG.=C2=A0 I person=
ally think this could be quite effective for WGs with 30 or less participan=
ts (including tourists).=C2=A0 I think a horseshoe layout can work for a gr=
oup that size.=C2=A0 Although I personally like the idea of having a horses=
hoe for 12-18 and having people, that are there just to have a table to put=
 their computer to type or read email, sit in classroom style seating behin=
d the horseshoe. =C2=A0=C2=A0
Mary.=C2=A0

On Mon, Sep 22, 2014=
 at 11:55 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrot=
e:
Hi Pete,



Over the last few years, I have mostly participated remotely, so my interes=
t is somewhat academic. Having said that, IMHO this is not a good idea, at =
least for my WG.



Like most working groups, we have the active participants and the tourists.=
 A central table can easily accommodate the regular participants but the cu=
rrent proposal ("additional rows of chairs around [the table] to accom=
modate everyone") will have most of the non-regulars in the back of th=
e room, effectively excluded from the discussion.



I think it is our job to encourage the non-regulars to participate, and thi=
s idea would run counter to that.



Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


On 09/22/2014 04:41 PM, Pete Resnick wrote:


Lars Eggert, IRTF Chair, has been talking with the research group chairs
about ways to make their meetings more effective, and one topic that

came up, is that when some of the research groups meet in one of the

smaller "round table" conference rooms, they tend to have discuss=
ions,

and when they meet in one of the IETF working group meeting rooms, they

tend to have presentations with a few people asking questions, and

almost no discussion. At least a couple of the research group chairs

have asked to meet in "round table configurations".



The IESG would like to find out whether there are IETF working groups

that would like to experiment with similar room configurations during

IETF 92 in Dallas.



We recognize that the constraints on IETF working groups aren't the sam=
e

as for IRTF research groups. BCP 25, "IETF Working Group Guidelines an=
d

Procedures", says "participation is open to all", so we woul=
d need to

ensure that working group participants aren't excluded simply because
room size, and that remote participants are supported at least as well

as today. That likely translates into a meeting room about the size

working groups typically usually use today, but with a large conference

table surrounded by chairs, plus additional rows of chairs around it to

accommodate everyone, with additional microphones around the table, and

mics elsewhere in the room available to everyone, etc. (The ISOC

Advisory Council meetings that meet on the Friday of IETF week use a

similar setup, if you have ever attended one of their meetings.)



But before we ask folks who are skilled in the art to figure out (for

instance) what Meetecho could do for remote participants in a room

configuration like this, we want to ask working group chairs if you

would like to participate in an experiment with your working group(s),

at IETF 92 in Dallas.



Pete & Spencer, for the IESG









--047d7b5d91ef52ef070503abd3bb--


From nobody Mon Sep 22 12:29:26 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695E71A1BF7 for ; Mon, 22 Sep 2014 12:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.787
X-Spam-Level: 
X-Spam-Status: No, score=-7.787 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 WsrMDrSWtwt5 for ; Mon, 22 Sep 2014 12:29:23 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8851A1BB3 for ; Mon, 22 Sep 2014 12:29:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411414150; x=1442950150; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gtVLViMqRasCiu/JCSWn95qkRPAUgq+MfT6wNgIHePk=; b=ddxkYbT4gwQBIPJ4vTjmzInv0YKALOU5r7aAUR5JuHnIGVdP126i2qgO cq5/Ib1GgJdz1qmTkn339hJHU1BQJt89jYHQBaxy8oETfFYnW8So+3mHS vBDZTrykt3j5NkQfZS5YFEtrx4lynPBB6wXDAlgy39l1p6xv1YlJdFvos I=;
X-IronPort-AV: E=McAfee;i="5600,1067,7569"; a="74658894"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Sep 2014 12:29:09 -0700
X-IronPort-AV: E=Sophos;i="5.04,573,1406617200"; d="scan'208";a="715796772"
Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Sep 2014 12:29:09 -0700
Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 22 Sep 2014 12:29:08 -0700
Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 22 Sep 2014 12:29:01 -0700
Message-ID: <54207879.6060809@qti.qualcomm.com>
Date: Mon, 22 Sep 2014 14:28:57 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Michael Richardson 
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
References: <54202706.7030501@qti.qualcomm.com> <20052.1411407505@sandelman.ca>
In-Reply-To: <20052.1411407505@sandelman.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/Arh_D6ae7fWnxb_fMJX3tg0Pb8g
Cc: WG Chairs , Spencer Dawkins 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 19:29:24 -0000

On 9/22/14 12:38 PM, Michael Richardson wrote:
> Pete Resnick, wrote:
>      >  translates into a meeting room about the size working groups typically
>      >  usually use today, but with a large conference table surrounded by
>      >  chairs,
>
> Do you mean a single table, or a square of tables, with an empty space in the
> middle?
>    

I expect whether it's a single table or a square of tables, with or 
without an empty space in the middle, will depend on the size requested.

pr

-- 
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478


From nobody Mon Sep 22 13:29:21 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BCF1A1B2E for ; Mon, 22 Sep 2014 13:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 aNExg3p-Nnzu for ; Mon, 22 Sep 2014 13:29:15 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE981A1AE0 for ; Mon, 22 Sep 2014 13:29:13 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id w7so2692862lbi.35 for ; Mon, 22 Sep 2014 13:29:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SJVh53uozW8ivTdKSAteG8132SAdZVI4u43Yx0N/L7Q=; b=HmYIPfsm1IRrpsjGpNSWSjFXgGbg2OxrRQLcIcadqXVbU15PYWdkoRPRV1czQY1/b+ UOpdO1CGbhvQB55frdv8JMYttOR7b0OwFzDaH1oAy4jeL5j0TecA4gJY5f/lUOiQY0Gh nRfbUMyxHb5zUu9lSnbzzrwVfMFssRE1zjL0j9BkXYVLLxQJkHfZ+nLJxNDtpgxRAlan cV7BJRUtbaoRuxXULnO03mK/yXOr+DoxlWs5SKbzqpswO2sdBajDEaV4Y+KiXq0wQ9I/ Vl3ya9DVl2zGKNavbIS1XME2Qv5PYKPlmJYH4mYV0bHYK7s6lAyCRORzbFyR7F1cfy1O +qBg==
MIME-Version: 1.0
X-Received: by 10.152.170.227 with SMTP id ap3mr27912924lac.15.1411417751576;  Mon, 22 Sep 2014 13:29:11 -0700 (PDT)
Received: by 10.152.206.36 with HTTP; Mon, 22 Sep 2014 13:29:09 -0700 (PDT)
Received: by 10.152.206.36 with HTTP; Mon, 22 Sep 2014 13:29:09 -0700 (PDT)
In-Reply-To: <54205A75.8090808@qti.qualcomm.com>
References: <54202706.7030501@qti.qualcomm.com> <54205496.9050503@gmail.com> <54205A75.8090808@qti.qualcomm.com>
Date: Mon, 22 Sep 2014 15:29:09 -0500
Message-ID: 
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
From: Spencer Dawkins at IETF 
To: Pete Resnick 
Content-Type: multipart/alternative; boundary=089e013c6558b664b40503ad4d12
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/-ix5oE17vyZvWzXo83vmtE3Ueto
Cc: WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 20:29:18 -0000

--089e013c6558b664b40503ad4d12
Content-Type: text/plain; charset=UTF-8

On Sep 22, 2014 12:21 PM, "Pete Resnick"  wrote:
>
> On 9/22/14 11:55 AM, Yaron Sheffer wrote:
>>
>> Hi Pete,
>>
>> Over the last few years, I have mostly participated remotely, so my
interest is somewhat academic. Having said that, IMHO this is not a good
idea, at least for my WG.
>>
>> Like most working groups, we have the active participants and the
tourists. A central table can easily accommodate the regular participants
but the current proposal ("additional rows of chairs around [the table] to
accommodate everyone") will have most of the non-regulars in the back of
the room, effectively excluded from the discussion.
>
>
> For some WG's, we'll be able to get everyone around the table. For
others, perhaps set up like the ISOC AC meetings, you'll have three sides
of the table have just a few rows each of chairs set up behind those
sitting at the table, so it's not like the "back of the room" is all that
far back. And you'll note that below we mentioned "mics elsewhere in the
room available to everyone"; the expectation is that anyone in the room
could get up to a mic and speak. I don't think that's "effectively
excluded". But I don't want to dismiss your point: I agree that it does
change the dynamic, and folks at the table (and perhaps the immediate row
behind) are much more likely to feel comfortable participating than folks
further back. That said:
>
>> I think it is our job to encourage the non-regulars to participate, and
this idea would run counter to that.
>
>
> While I think it is *a* job of the chair to encourage non-regulars to
participate, it's certainly not the *primary* job. Getting productive work
done is. Making it seem more open to non-regulars *at the expense of*
productivity is probably not a great idea either. The reason for this
experiment is because we've heard that there are WGs where it would help
productivity to move away from the lecture/Q&A style format to a more
round-table discussion format. I've certainly chaired WGs where we could
get everyone (participants and just observers) around a single table, and
others that could be accommodated with just a couple of rows of additional
seating, and could have benefited tremendously from getting rid of the
"presentation format". Perhaps there are WGs where this doesn't make sense
at all. But this is why we expect this to be the choice of the chair and
the WG. The question is whether anyone of you would like to give it a shot.

For what it's worth, I'm sure there are working groups this experimental
format would not work for, at all. The question is whether it would work
for some WGs.

Amusingly, we've had several conversations within the IESG where one AD
said, "obviously, you couldn't do this in WG X", and another AD said "
actually, this is the format they use for interims".

After a couple of rounds of that, we decided to ask the chairs :-)

Spencer

> pr
>
>
>> On 09/22/2014 04:41 PM, Pete Resnick wrote:
>>>
>>> Lars Eggert, IRTF Chair, has been talking with the research group chairs
>>> about ways to make their meetings more effective, and one topic that
>>> came up, is that when some of the research groups meet in one of the
>>> smaller "round table" conference rooms, they tend to have discussions,
>>> and when they meet in one of the IETF working group meeting rooms, they
>>> tend to have presentations with a few people asking questions, and
>>> almost no discussion. At least a couple of the research group chairs
>>> have asked to meet in "round table configurations".
>>>
>>> The IESG would like to find out whether there are IETF working groups
>>> that would like to experiment with similar room configurations during
>>> IETF 92 in Dallas.
>>>
>>> We recognize that the constraints on IETF working groups aren't the same
>>> as for IRTF research groups. BCP 25, "IETF Working Group Guidelines and
>>> Procedures", says "participation is open to all", so we would need to
>>> ensure that working group participants aren't excluded simply because
>>> room size, and that remote participants are supported at least as well
>>> as today. That likely translates into a meeting room about the size
>>> working groups typically usually use today, but with a large conference
>>> table surrounded by chairs, plus additional rows of chairs around it to
>>> accommodate everyone, with additional microphones around the table, and
>>> mics elsewhere in the room available to everyone, etc. (The ISOC
>>> Advisory Council meetings that meet on the Friday of IETF week use a
>>> similar setup, if you have ever attended one of their meetings.)
>>>
>>> But before we ask folks who are skilled in the art to figure out (for
>>> instance) what Meetecho could do for remote participants in a room
>>> configuration like this, we want to ask working group chairs if you
>>> would like to participate in an experiment with your working group(s),
>>> at IETF 92 in Dallas.
>>>
>>> Pete & Spencer, for the IESG
>>>
>>
>
> --
> Pete Resnick
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>

--089e013c6558b664b40503ad4d12
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Sep 22, 2014 12:21 PM, "Pete Resnick" <presnick@qti.qualcomm.com> wrote:

>

> On 9/22/14 11:55 AM, Yaron Sheffer wrote:

>>

>> Hi Pete,

>>

>> Over the last few years, I have mostly participated remotely, so m=
y interest is somewhat academic. Having said that, IMHO this is not a good =
idea, at least for my WG.

>>

>> Like most working groups, we have the active participants and the =
tourists. A central table can easily accommodate the regular participants b=
ut the current proposal ("additional rows of chairs around [the table]=
 to accommodate everyone") will have most of the non-regulars in the b=
ack of the room, effectively excluded from the discussion.

>

>

> For some WG's, we'll be able to get everyone around the table.=
 For others, perhaps set up like the ISOC AC meetings, you'll have thre=
e sides of the table have just a few rows each of chairs set up behind thos=
e sitting at the table, so it's not like the "back of the room&quo=
t; is all that far back. And you'll note that below we mentioned "=
mics elsewhere in the room available to everyone"; the expectation is =
that anyone in the room could get up to a mic and speak. I don't think =
that's "effectively excluded". But I don't want to dismis=
s your point: I agree that it does change the dynamic, and folks at the tab=
le (and perhaps the immediate row behind) are much more likely to feel comf=
ortable participating than folks further back. That said:

>

>> I think it is our job to encourage the non-regulars to participate=
, and this idea would run counter to that.

>

>

> While I think it is *a* job of the chair to encourage non-regulars to =
participate, it's certainly not the *primary* job. Getting productive w=
ork done is. Making it seem more open to non-regulars *at the expense of* p=
roductivity is probably not a great idea either. The reason for this experi=
ment is because we've heard that there are WGs where it would help prod=
uctivity to move away from the lecture/Q&A style format to a more round=
-table discussion format. I've certainly chaired WGs where we could get=
 everyone (participants and just observers) around a single table, and othe=
rs that could be accommodated with just a couple of rows of additional seat=
ing, and could have benefited tremendously from getting rid of the "pr=
esentation format". Perhaps there are WGs where this doesn't make =
sense at all. But this is why we expect this to be the choice of the chair =
and the WG. The question is whether anyone of you would like to give it a s=
hot.
For what it's worth, I'm sure there are working grou=
ps this experimental format would not work for, at all. The question is whe=
ther it would work for some WGs.
Amusingly, we've had several conversations within the IE=
SG where one AD said, "obviously, you couldn't do this in WG X&quo=
t;, and another AD said " actually, this is the format they use for in=
terims".
After a couple of rounds of that, we decided to ask the chai=
rs :-)
Spencer
> pr

>

>

>> On 09/22/2014 04:41 PM, Pete Resnick wrote:

>>>

>>> Lars Eggert, IRTF Chair, has been talking with the research gr=
oup chairs

>>> about ways to make their meetings more effective, and one topi=
c that

>>> came up, is that when some of the research groups meet in one =
of the

>>> smaller "round table" conference rooms, they tend to=
 have discussions,

>>> and when they meet in one of the IETF working group meeting ro=
oms, they

>>> tend to have presentations with a few people asking questions,=
 and

>>> almost no discussion. At least a couple of the research group =
chairs

>>> have asked to meet in "round table configurations".<=
br>
>>>

>>> The IESG would like to find out whether there are IETF working=
 groups

>>> that would like to experiment with similar room configurations=
 during

>>> IETF 92 in Dallas.

>>>

>>> We recognize that the constraints on IETF working groups aren&=
#39;t the same

>>> as for IRTF research groups. BCP 25, "IETF Working Group =
Guidelines and

>>> Procedures", says "participation is open to all"=
;, so we would need to

>>> ensure that working group participants aren't excluded sim=
ply because

>>> room size, and that remote participants are supported at least=
 as well

>>> as today. That likely translates into a meeting room about the=
 size

>>> working groups typically usually use today, but with a large c=
onference

>>> table surrounded by chairs, plus additional rows of chairs aro=
und it to

>>> accommodate everyone, with additional microphones around the t=
able, and

>>> mics elsewhere in the room available to everyone, etc. (The IS=
OC

>>> Advisory Council meetings that meet on the Friday of IETF week=
 use a

>>> similar setup, if you have ever attended one of their meetings=
.)

>>>

>>> But before we ask folks who are skilled in the art to figure o=
ut (for

>>> instance) what Meetecho could do for remote participants in a =
room

>>> configuration like this, we want to ask working group chairs i=
f you

>>> would like to participate in an experiment with your working g=
roup(s),

>>> at IETF 92 in Dallas.

>>>

>>> Pete & Spencer, for the IESG

>>>

>>

>

> -- 

> Pete Resnick<http://=
www.qualcomm.com/~presnick/>

> Qualcomm Technologies, Inc. - +1 (858)651-4478

>



--089e013c6558b664b40503ad4d12--


From nobody Mon Sep 22 13:48:35 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB691A1AC1 for ; Mon, 22 Sep 2014 13:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 So_zv9zo_bqy for ; Mon, 22 Sep 2014 13:48:32 -0700 (PDT)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61FC21A02A0 for ; Mon, 22 Sep 2014 13:48:32 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id y10so5177042pdj.3 for ; Mon, 22 Sep 2014 13:48:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oX5EgYLbwSR78yJeHxrhwLkQ7uVCdiEuZJFOTrcHgkU=; b=V77spJwt9CAg8nzGdY7qo+bj5JcuoJseqpdk51dX3aEgD/+NfybUTfun1rvL7+eygZ JDneCImtSOoa3ZzUPKfHm6eR1sMVKwbITpyWwGKMM0IKzlAl8FZym0LKHKnxD4yo2Esk uexRjCWxF1UKi3Ee3oD0HbMvGu01EAPRyX3sn8vro0HqxylkbNrkgWgWsd+n6N6wrQ7V eF2GL0O3FPt3QxOqQnLeG1OblSgVFX1mrjLHEQ34j5ANOfG3E30qxqHqdGLFDVHDHE0l K9q6JTS9m+2t2+RF8Qmbl9QWGHZhv+7AC1Jk0VChqSYTfZxiggENjujqrWk4xUCELGWc em/Q==
X-Received: by 10.68.203.5 with SMTP id km5mr27334436pbc.91.1411418912074; Mon, 22 Sep 2014 13:48:32 -0700 (PDT)
Received: from [192.168.178.23] (145.200.69.111.dynamic.snap.net.nz. [111.69.200.145]) by mx.google.com with ESMTPSA id i9sm10159328pbq.17.2014.09.22.13.48.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Sep 2014 13:48:30 -0700 (PDT)
Message-ID: <54208B1C.4030000@gmail.com>
Date: Tue, 23 Sep 2014 08:48:28 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Pete Resnick 
Subject: Re: [BOFChairs] Meeting room layout experiment at IETF 92 in Dallas
References: <54202706.7030501@qti.qualcomm.com> <20052.1411407505@sandelman.ca> <54207879.6060809@qti.qualcomm.com>
In-Reply-To: <54207879.6060809@qti.qualcomm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/AUffbcetl5_r5WhBe-dDN98dyB4
Cc: Michael Richardson , Spencer Dawkins , WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Sep 2014 20:48:33 -0000

On 23/09/2014 07:28, Pete Resnick wrote:
> On 9/22/14 12:38 PM, Michael Richardson wrote:
>> Pete Resnick, wrote:
>>      >  translates into a meeting room about the size working groups
>> typically
>>      >  usually use today, but with a large conference table
>> surrounded by
>>      >  chairs,
>>
>> Do you mean a single table, or a square of tables, with an empty space
>> in the
>> middle?
>>    
> 
> I expect whether it's a single table or a square of tables, with or
> without an empty space in the middle, will depend on the size requested.

I think it depends tremendously on the style of the WG and whether it
is one that has a relatively small, intense group of active contributors
vs one that has a wide range of less active contributors. In the first
case, it's fine and would increase effectiveness, and in the second
case it would create a harmful first class/second class split among the
contributors, since the people not sitting at the main table would
find it much harder to break into the conversation. It would also
confuse and complicate the microphone discipline, which we need for
remote participants.

And like it or not, everybody needs to see the screen. Whatever your
view on the merits of Powerpoint, there is always a need to see
the screen.

BTW, there was an experiment in 2005, stimulated by Alex Zinin, in
using a "herring bone" or semi-circular setup, so that the setting
was more intimate even with 100 or more people in the room. It didn't
catch on but I thought it was an interesting idea. It might be worth
another try.

   Brian


From nobody Mon Sep 22 20:54:32 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FF11A19FF for ; Mon, 22 Sep 2014 20:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.688
X-Spam-Level: 
X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable
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 n3Fbd4oy98uW for ; Mon, 22 Sep 2014 20:54:29 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FD71A19FC for ; Mon, 22 Sep 2014 20:54:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,577,1406617200";  d="asc'?scan'208";a="195817097"
Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx12-out.netapp.com with ESMTP; 22 Sep 2014 20:54:29 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 22 Sep 2014 20:53:40 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::79b6:a9a2:f48b:f065%21]) with mapi id 15.00.0913.011; Mon, 22 Sep 2014 20:53:40 -0700
From: "Eggert, Lars" 
To: Pete Resnick 
Subject: Re: Meeting room layout experiment at IETF 92 in Dallas
Thread-Topic: Meeting room layout experiment at IETF 92 in Dallas
Thread-Index: AQHP1m1jFembQKkQwEGNvGUxsHpnwJwOjKGA
Date: Tue, 23 Sep 2014 03:53:40 +0000
Message-ID: <646CA57F-7F6F-4F60-82AD-DB0D3FA0A2E4@netapp.com>
References: <54202706.7030501@qti.qualcomm.com>
In-Reply-To: <54202706.7030501@qti.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.1878.6)
x-originating-ip: [10.122.56.79]
Content-Type: multipart/signed; boundary="Apple-Mail=_66803BAC-CFDC-44A6-BDAF-F60CA64C9A44"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/MMiYttr-NgLx4JQPNy6qtkiSAXo
Cc: WG Chairs , "Internet Research Steering Group \(irsg@irtf.org\)" 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Sep 2014 03:54:31 -0000

--Apple-Mail=_66803BAC-CFDC-44A6-BDAF-F60CA64C9A44
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

CC'ing the IRSG

On 2014-9-22, at 19:11, Pete Resnick  wrote:

> Lars Eggert, IRTF Chair, has been talking with the research group =
chairs about ways to make their meetings more effective, and one topic =
that came up, is that when some of the research groups meet in one of =
the smaller "round table" conference rooms, they tend to have =
discussions, and when they meet in one of the IETF working group meeting =
rooms, they tend to have presentations with a few people asking =
questions, and almost no discussion. At least a couple of the research =
group chairs have asked to meet in "round table configurations".
>=20
> The IESG would like to find out whether there are IETF working groups =
that would like to experiment with similar room configurations during =
IETF 92 in Dallas.
>=20
> We recognize that the constraints on IETF working groups aren't the =
same as for IRTF research groups. BCP 25, "IETF Working Group Guidelines =
and Procedures", says "participation is open to all", so we would need =
to ensure that working group participants aren't excluded simply because =
room size, and that remote participants are supported at least as well =
as today. That likely translates into a meeting room about the size =
working groups typically usually use today, but with a large conference =
table surrounded by chairs, plus additional rows of chairs around it to =
accommodate everyone, with additional microphones around the table, and =
mics elsewhere in the room available to everyone, etc. (The ISOC =
Advisory Council meetings that meet on the Friday of IETF week use a =
similar setup, if you have ever attended one of their meetings.)
>=20
> But before we ask folks who are skilled in the art to figure out (for =
instance) what Meetecho could do for remote participants in a room =
configuration like this, we want to ask working group chairs if you =
would like to participate in an experiment with your working group(s), =
at IETF 92 in Dallas.
>=20
> Pete & Spencer, for the IESG
>=20


--Apple-Mail=_66803BAC-CFDC-44A6-BDAF-F60CA64C9A44
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBVCDu89ZcnpRveo1xAQK51wQAiBy75NHB9w0kW/8IdpFTXfxieXqC4f+I
Vaf4IxNV/reyRy/RphEe7pHWdK5OA7eMEiAn5ccT6OMSHBu/AT1/ylp3DpU+OQZJ
9bZsz9iMElGkrWoj3EznhK6jst2/a4l7dtxPpJXAzhr9jzPAq2sCr1B2P2ss7Qfv
+PF7x45MH30=
=MKR5
-----END PGP SIGNATURE-----

--Apple-Mail=_66803BAC-CFDC-44A6-BDAF-F60CA64C9A44--


From nobody Tue Sep 23 18:34:47 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C791A89AF for ; Tue, 23 Sep 2014 18:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.587
X-Spam-Level: 
X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 OHIoEgjFGXAV for ; Tue, 23 Sep 2014 18:34:45 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DEA51A89AE for ; Tue, 23 Sep 2014 18:34:44 -0700 (PDT)
X-AuditID: 1209190e-f79d46d000003643-01-54221fb35638
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 95.4A.13891.3BF12245; Tue, 23 Sep 2014 21:34:43 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s8O1Yh8u015123 for ; Tue, 23 Sep 2014 21:34:43 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8O1YfxU027839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Sep 2014 21:34:43 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8O1YfGB029427; Tue, 23 Sep 2014 21:34:41 -0400 (EDT)
Date: Tue, 23 Sep 2014 21:34:41 -0400 (EDT)
From: Benjamin Kaduk 
To: WG Chairs 
Subject: best practices for dealing with DMARC fallout on IETF lists
Message-ID: 
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUixG6nrrtZXinE4PtbU4v/+6cwOjB6LFny kymAMYrLJiU1J7MstUjfLoErY1+Ld8Ec5opP134zNjCeZOpi5OSQEDCRWH/pIjuELSZx4d56 ti5GLg4hgdlMEhcOvYVyTjJKdP+4ywjh3GKSeNx3jwXCaWCUWHD0KpDDwcEioC1xfZ0gyCg2 ARWJmW82soHYIgKKEu/fdIPZwgIuEmt3zWIDKecVcJTYulADJCwqoCOxev8UFhCbV0BQ4uTM J2A2s4CWxPLp21gmMPLNQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5q SukmRlAocUry7WD8elDpEKMAB6MSD+9EcaUQIdbEsuLK3EOMkhxMSqK8XySBQnxJ+SmVGYnF GfFFpTmpxYcYJTiYlUR4ua8phgjxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJ ynBwKEnwqssBDRUsSk1PrUjLzClBSDNxcIIM5wEangRSw1tckJhbnJkOkT/FaMzR0vS2l4lj Xee3fiYhlrz8vFQpcV41kFIBkNKM0jy4abB08IpRHOg5YV5WkCoeYCqBm/cKaBUT0Kr7x+VB VpUkIqSkGhh15skfztwvL9vaJHe6yH/50/dPbiu9Slohln/nXZNaQVz398OzTgvFsUj2lM2e s0fv1loPLsGvjblnebSWFtYcskk+eml3yWPVivs25gwRsce2hKpN3tx3/c9UqX0yzO6XgwQK YqZ/+nvq0JI/k0QlPLT2Nf9/Frz4jvHHFSszxETP1Z1pOhylxFKckWioxVxUnAgA00HhH+IC AAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/zODuK9QN5n1Fyk4yoAzWN5Kpnec
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 01:34:46 -0000

Hi all,

We had mailman disable several subscriptions to the kitten list recently,
due to what appears to be DMARC fallout.

Are there best practices for what the WG chairs should do in response, in
terms of notifying those addresses which were dropped, or pestering the
IETF mailman administrators to upgrade to the latest version which does
not break DMARC, or some other action(s)?

Thanks,

Ben


From nobody Tue Sep 23 21:31:38 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CC81A8A76 for ; Tue, 23 Sep 2014 21:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 X9xCAX5dvVon for ; Tue, 23 Sep 2014 21:31:36 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942741A8A73 for ; Tue, 23 Sep 2014 21:31:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1510; q=dns/txt; s=iport; t=1411533096; x=1412742696; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=KRWETGg0DFkbkmrP8SlgWCJDFfBju8eEcsKcmrik79M=; b=l4o/iqUq+FrAZP1n21QI8N815376eI1HVMNzDagccJqYSozTzcJ2NPEQ sFcIvd1tnd/aM9bPPReD9JrZxrdlTOG2qNsIUnb8BoDQY23f8By/NOJim QwVLU8SV3xik+tAlos/9e7YlU0Y4Vz31e9cfjkSRz85siRWAoNFa4En0t Q=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIEACdIIlStJssW/2dsb2JhbABgDocrzmIBgR0BeoQEAQEEI1URCxgJFgsCAgkDAgECAUUGAQwIAQGIOqxKlg0BF5AOgniBUwEEk2SBS4dth0yOB4FngTtCO4J5AQEB
X-IronPort-AV: E=Sophos;i="5.04,586,1406592000";  d="asc'?scan'208";a="187686898"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 24 Sep 2014 04:31:34 +0000
Received: from [10.61.195.96] ([10.61.195.96]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8O4VX9Z027737; Wed, 24 Sep 2014 04:31:33 GMT
Message-ID: <54224924.6080808@cisco.com>
Date: Wed, 24 Sep 2014 06:31:32 +0200
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Benjamin Kaduk , WG Chairs 
Subject: Re: best practices for dealing with DMARC fallout on IETF lists
References: 
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RHmb0ItRJXdQB1DLQF11G34efQhsjQa7j"
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/WOypXCJKJDjPSPJSvlBuHl8oA94
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 04:31:37 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--RHmb0ItRJXdQB1DLQF11G34efQhsjQa7j
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Did mailman report this so that you know when they fell off?

Eliot

On 9/24/14, 3:34 AM, Benjamin Kaduk wrote:
> Hi all,
>
> We had mailman disable several subscriptions to the kitten list recentl=
y,
> due to what appears to be DMARC fallout.
>
> Are there best practices for what the WG chairs should do in response, =
in
> terms of notifying those addresses which were dropped, or pestering the=

> IETF mailman administrators to upgrade to the latest version which does=

> not break DMARC, or some other action(s)?
>
> Thanks,
>
> Ben
>
>
>



--RHmb0ItRJXdQB1DLQF11G34efQhsjQa7j
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQEcBAEBAgAGBQJUIkkkAAoJEIe2a0bZ0nozNaAH/jBhQuPrT0aC/SonXgHq8uBJ
VSKIQSIbdRKFXPEOsdz6NamoOd/v/AStlIV6cmkmXRM3Z+gsvccpuOKeLkON4tWL
Mkg+G2UrcxC7HQo9aMyXW3UKXLOR9PpR26t9I2E/KRBIR1L6dlsSXDFswGvYkwj1
YE8vi07omLbQzCxpn5f0NJltorkWqb9qoP4yxldoymN3IqLoveF7ozXqgy4+kSla
9pTUB/sXSvdPW5m4RfkXp4hlaD8TuUnjdkoCmryakUGLHj/8lLhbD4ros3N1R9zD
orA2MxdNQ8jzcYW4Is6nf7QUQwPbC5v3cMk+oU/YhOMccWbVII1nABwnswbEm/g=
=ecHS
-----END PGP SIGNATURE-----

--RHmb0ItRJXdQB1DLQF11G34efQhsjQa7j--


From nobody Tue Sep 23 21:36:40 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26B01A8A95 for ; Tue, 23 Sep 2014 21:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 lD56X7gkkDnC for ; Tue, 23 Sep 2014 21:36:37 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B18B1A8A7F for ; Tue, 23 Sep 2014 21:36:15 -0700 (PDT)
X-AuditID: 12074424-f79346d000004923-bc-54224a3e27ab
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 61.A4.18723.E3A42245; Wed, 24 Sep 2014 00:36:14 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s8O4aDmL015065; Wed, 24 Sep 2014 00:36:13 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8O4aBTd014477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Sep 2014 00:36:13 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8O4aB7Z022111; Wed, 24 Sep 2014 00:36:11 -0400 (EDT)
Date: Wed, 24 Sep 2014 00:36:11 -0400 (EDT)
From: Benjamin Kaduk 
To: Eliot Lear 
Subject: Re: best practices for dealing with DMARC fallout on IETF lists
In-Reply-To: <54224924.6080808@cisco.com>
Message-ID: 
References:  <54224924.6080808@cisco.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixG6nomvnpRRicHMGj8XXfx0sFv/3T2F0 YPKY8nsjq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJO3v7KWnCMqeLEae8GxgamLkZODgkBE4ne C1tZIWwxiQv31rN1MXJxCAnMZpK4f/QdO4SzkVHi7O9nUJlDTBILe1qYIJwGRol/d7cxgvSz CGhLzG9YyQ5iswmoSMx8s5ENxBYRkJdoPbsfbAezgKLE+rWTwGxhAQ+Jm3eWMIPYnAKaEr2N N8BsXgFHiT87boPNERKIk2j62g9miwroSKzeP4UFokZQ4uTMJywQM7Uklk/fxjKBUXAWktQs JKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdM31cjNL9FJTSjcxgkPVRWUHY/MhpUOMAhyM Sjy8E8SVQoRYE8uKK3MPMUpyMCmJ8m4wBQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4d2nCpTj TUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLg1fMEahQsSk1PrUjLzClB SDNxcIIM5wEaLgxSw1tckJhbnJkOkT/FaMzR0vS2l4ljXee3fiYhlrz8vFQpcV5/D6BSAZDS jNI8uGmwdPOKURzoOWHeiyBVPMBUBTfvFdAqJqBV94/Lg6wqSURISTUw6qxj4Cr1v9a+6Gyk zpmas+u+deYe6H1kE3Ken7dt2wXjp5cOHX7xdvmDqatO5Us7n2N9cfZz5VSVykNSiUmv/h4P untd4rBwOt+Xv2b2k97wLJsROVGP5waL5MFEGa477neqjwvLHQ65drd37UKuczen6//7tFfw TdKflW9D29XCOYUT9eYomCuxFGckGmoxFxUnAgA+1LHHEgMAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/EswPjOacxIt7H0PJ4q9cHcCWZAg
Cc: WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 04:36:39 -0000

On Wed, 24 Sep 2014, Eliot Lear wrote:

> Did mailman report this so that you know when they fell off?

Yes; I got a bunch of reports Monday night with the addresses whose
subscriptions were disabled, and what appear to be the original bounce
messages (which I have not spent too much time trying to decipher).

-Ben


From nobody Tue Sep 23 21:51:02 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE2F1A8A82 for ; Tue, 23 Sep 2014 21:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 rqnjaTNWXzy7 for ; Tue, 23 Sep 2014 21:51:00 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31EB81A8A7F for ; Tue, 23 Sep 2014 21:51:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3732; q=dns/txt; s=iport; t=1411534261; x=1412743861; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=H3TAG92mAMnwG+G32A2ZGibVP6MFPxmg6cSRszx7Rvw=; b=b4nHYZeQ7bByH0kNBpUu4ls02fGKSsFowXCzjw8TjNUVS0sBfV3k6VR9 PRg9Y1EBFX3yBCVaSnf/E8RjRQcBkS3+KvX8rDZLsH7ce2whERP9keXYS 9f+Bm+ayavL4VLdTCCBwAoqJnNOqeLt8dNEBtsAScQpYKF7DClsy3J4iI I=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMEAMxMIlStJssW/2dsb2JhbABgDocrzmYBgR0BeoQEAQEEI1UBEAsEARMJFgsCAgkDAgECAUUGDQEHAQGIOqxBlhABF482AQFPB4J4gVMBBJNkgUuHbYdMjgeDIkI7gT6BOwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,586,1406592000";  d="asc'?scan'208,217";a="187701976"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 24 Sep 2014 04:50:59 +0000
Received: from [10.61.195.96] ([10.61.195.96]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8O4owIg032091; Wed, 24 Sep 2014 04:50:58 GMT
Message-ID: <54224DB1.9030607@cisco.com>
Date: Wed, 24 Sep 2014 06:50:57 +0200
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Benjamin Kaduk 
Subject: Re: best practices for dealing with DMARC fallout on IETF lists
References:  <54224924.6080808@cisco.com> 
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2ewN8B18B5EA7wpq4mtItP3xJVhXQ1Bqc"
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/HAZZ1yyChsEFNGYaK8mHkWIAsKo
Cc: WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 04:51:01 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2ewN8B18B5EA7wpq4mtItP3xJVhXQ1Bqc
Content-Type: multipart/alternative;
 boundary="------------050000060407070809020103"

This is a multi-part message in MIME format.
--------------050000060407070809020103
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

To answer your question as to whether there are best practices, not that
I am aware.  Here's at least a start at a suggested approach, if it helps=
=2E

 1. Reinstate the individuals immediately;
 2. Inform them of the problem, including when they were disabled;
 3. Provide an explanation as to why it happened; and
 4. Point them at the mail archive.

Others?

Also, another tools question: do we know if the disabled subscribers'
other subscriptions were impacted?

Eliot

On 9/24/14, 6:36 AM, Benjamin Kaduk wrote:
> On Wed, 24 Sep 2014, Eliot Lear wrote:
>
>> Did mailman report this so that you know when they fell off?
> Yes; I got a bunch of reports Monday night with the addresses whose
> subscriptions were disabled, and what appear to be the original bounce
> messages (which I have not spent too much time trying to decipher).
>
> -Ben
>
>


--------------050000060407070809020103
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    To answer your question as to whether there are best practices, not
    that I am aware.=C2=A0 Here's at least a start at a suggested approac=
h,
    if it helps.

    

    
      Reinstate the individuals immediately;
      Inform them of the problem, including when they were disabled;<=
/li>
      
Provide an explanation as to why it happened; and

      
      Point them at the mail archive.
    
    Others?

    
    Also, another tools question: do we know if the disabled
      subscribers' other subscriptions were impacted?

    
    Eliot

      

    
    On 9/24/14, 6:36 AM, Benjamin Kaduk
      wrote:

    
    
      On Wed, 24 Sep 2014, Eliot Lear wrote:


      
        Did mailman report this so that you know when they=
 fell off?

      
      Yes; I got a bunch of reports Monday night with the addresses whose
subscriptions were disabled, and what appear to be the original bounce
messages (which I have not spent too much time trying to decipher).

-Ben



    
    

  


--------------050000060407070809020103--

--2ewN8B18B5EA7wpq4mtItP3xJVhXQ1Bqc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQEcBAEBAgAGBQJUIk2xAAoJEIe2a0bZ0noz+C8H+wYzZYNWhPHonMYvPVIOQpIo
QNfj9DJaxH6HvMStmdkrCXeNyg24IkRbO0XY6u2VdpCoL0s13jq9DLCYnF3ZT9QA
Wf5WNnQRQPCMiYArER+L2DYpeAMlrfOU1ZAVD5GVhC4pPWJPv3wTbNAuwaZEJp/4
GkRvPGDK3E4Drizz5Bx+i/pDDbvk/z1CLqt4ZBiNguiXQwJdSnl4+J0JO6ddINFY
GXMnAwAL4DuGgKG6TSKt+xoWcpLPxfe5owAAIx0t806l2kyD9kFljQaZI5Rbu3/Z
RmVElHZ0D+l1A+1vZW+F9Sjgx3afj2zhLlOaNQ7CyMDq3lqSivRmqUBNtqmyfEg=
=vCBL
-----END PGP SIGNATURE-----

--2ewN8B18B5EA7wpq4mtItP3xJVhXQ1Bqc--


From nobody Wed Sep 24 06:53:12 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B51F1A00E4 for ; Wed, 24 Sep 2014 06:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.077
X-Spam-Level: 
X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
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 OcC91-wksVTS for ; Wed, 24 Sep 2014 06:53:09 -0700 (PDT)
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 D6F6A1A00C0 for ; Wed, 24 Sep 2014 06:53:08 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E9D2720012; Wed, 24 Sep 2014 09:58:21 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 536B463AE9; Wed, 24 Sep 2014 09:53:04 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 395BA63AD5; Wed, 24 Sep 2014 09:53:04 -0400 (EDT)
From: Michael Richardson 
To: Eliot Lear 
Subject: Re: best practices for dealing with DMARC fallout on IETF lists
In-Reply-To: <54224DB1.9030607@cisco.com>
References:  <54224924.6080808@cisco.com>  <54224DB1.9030607@cisco.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.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
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/9_mDbRwFzdSSEWCXBe7XHU4iFNE
Cc: WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 13:53:10 -0000

--=-=-=


Eliot Lear  wrote:
    > To answer your question as to whether there are best practices, not that
    > I am aware.  Here's at least a start at a suggested approach, if it helps.

    > 1. Reinstate the individuals immediately;
    > 2. Inform them of the problem, including when they were disabled;
    > 3. Provide an explanation as to why it happened; and
    > 4. Point them at the mail archive.

    > Others?

Unless I misunderstood, the people who were kicked off were kicked off
because their MTA processed the p=reject, and acted accordingly.  Those
subscribers were not at fault, nor was their MTA.  The problem was with other
subscribers who sent email from a p=reject, and those are the ones that
should be removed.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVCLMvYCLcPvd0N1lAQJ+ygf/bUhY8r1ro4BAMx6M7jpVk6YIj46ag/43
QtNTXJ1PYgQgAiQMR6cIwVOMbtbXPvNad0+iTD09c/vUhg9wtMR5heKl7KYSbv9L
H9pIl8kzP9rYqaZC8HqYjV9fR7c1NFk6sHfsaJ5OzNslDiLgWhsa9ZpESIzXfE6Y
0QWFpGVNm9ZjE16d/sy9l2iq1NEHh7ef6oLWRXh+XtVntACJ7jUYgk9VVOkfFVLt
zT/zC4QUqK+ka2eF5YKgPjt+WbynKTbK6CHcozccfp0iZ1dOQLqWhLWYf5i32Nmq
yn09bk15Xbtv/CAwN9tP0Tc4LXmNg5Ol5klDM6DtGT1Sb4W2D8biMw==
=L3Ka
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Sep 24 07:22:31 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB0F1A0140 for ; Wed, 24 Sep 2014 07:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.689
X-Spam-Level: 
X-Spam-Status: No, score=-0.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_16=0.6] autolearn=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 T0piC6PTGJfV for ; Wed, 24 Sep 2014 07:22:29 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28731A0123 for ; Wed, 24 Sep 2014 07:22:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 9E3D4E2046; Wed, 24 Sep 2014 10:22:27 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25176-10; Wed, 24 Sep 2014 10:22:25 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 46A63E2033; Wed, 24 Sep 2014 10:22:24 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s8OEMNKN015857; Wed, 24 Sep 2014 10:22:23 -0400
From: Derek Atkins 
To: Michael Richardson 
Subject: Re: best practices for dealing with DMARC fallout on IETF lists
References:  <54224924.6080808@cisco.com>  <54224DB1.9030607@cisco.com> <11835.1411566784@sandelman.ca>
Date: Wed, 24 Sep 2014 10:22:23 -0400
In-Reply-To: <11835.1411566784@sandelman.ca> (Michael Richardson's message of "Wed, 24 Sep 2014 09:53:04 -0400")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/yBsUx09IgqVpTev_BiGNzDuPGmQ
Cc: WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 14:22:30 -0000

Michael Richardson  writes:

> Eliot Lear  wrote:
>     > To answer your question as to whether there are best practices, not that
>     > I am aware.  Here's at least a start at a suggested approach, if it helps.
>
>     > 1. Reinstate the individuals immediately;
>     > 2. Inform them of the problem, including when they were disabled;
>     > 3. Provide an explanation as to why it happened; and
>     > 4. Point them at the mail archive.
>
>     > Others?
>
> Unless I misunderstood, the people who were kicked off were kicked off
> because their MTA processed the p=reject, and acted accordingly.  Those
> subscribers were not at fault, nor was their MTA.  The problem was with other
> subscribers who sent email from a p=reject, and those are the ones that
> should be removed.

Which means everyone with a yahoo.com address, among others.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant


From nobody Wed Sep 24 07:51:07 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892451A0123 for ; Wed, 24 Sep 2014 07:51:05 -0700 (PDT)
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, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=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 W5n5Tcjp6Kx1 for ; Wed, 24 Sep 2014 07:51:04 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0BF1A0114 for ; Wed, 24 Sep 2014 07:51:03 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id x13so3138487wgg.19 for ; Wed, 24 Sep 2014 07:51:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=v5Pn/H95jnY6zdfItUeQoWeZmCRFfpXHBgcnyxUf/Wk=; b=Zrue+rl9Z3z1lHYy8p6OJizeGhNwtq972EZGEWnVACHDO9rnsPpMQvt+BUORGF3GgZ maQIsgDj7QeexVr0AKNMu/V/BSvwx/OLoNGfV7bZov57/g3UbvdlO6Wso/Wb37MLVkQ2 dY9InOKPyPDI3Cipb+0Acb/s+hoPqxgTzcOJn8KgOvRMBS+DpBxClMhUFm97NmX1OoYZ /6AChM6uaOQ/O/s6EeW1RFm0t2hSbA4Q7aKJlaAbV5KOPlxKfGawhkCpjbdmV/J9xpqY 7WW2mZ/Yay+ngfQxqmHfnNjdYa16JLDwgRH4EZ8qZvSVODAtfPuLcE82xdgajjlmc7ZU ikuQ==
X-Received: by 10.180.95.68 with SMTP id di4mr31915956wib.60.1411570262567; Wed, 24 Sep 2014 07:51:02 -0700 (PDT)
Received: from [192.168.1.100] (IGLD-84-228-177-30.inter.net.il. [84.228.177.30]) by mx.google.com with ESMTPSA id gl10sm6250909wib.1.2014.09.24.07.51.01 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Sep 2014 07:51:01 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_377BC529-5D52-4B2B-9901-8053F676FC04"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: best practices for dealing with DMARC fallout on IETF lists
From: Yoav Nir 
In-Reply-To: 
Date: Wed, 24 Sep 2014 17:50:59 +0300
Message-Id: 
References:  <54224924.6080808@cisco.com>  <54224DB1.9030607@cisco.com> <11835.1411566784@sandelman.ca> 
To: Derek Atkins 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/18YRev2WVvgcR8awYV2y6lpscrA
Cc: Michael Richardson , WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 14:51:05 -0000

--Apple-Mail=_377BC529-5D52-4B2B-9901-8053F676FC04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Sep 24, 2014, at 5:22 PM, Derek Atkins  wrote:

> Michael Richardson  writes:
>=20
>> Eliot Lear  wrote:
>>> To answer your question as to whether there are best practices, not =
that
>>> I am aware.  Here's at least a start at a suggested approach, if it =
helps.
>>=20
>>> 1. Reinstate the individuals immediately;
>>> 2. Inform them of the problem, including when they were disabled;
>>> 3. Provide an explanation as to why it happened; and
>>> 4. Point them at the mail archive.
>>=20
>>> Others?
>>=20
>> Unless I misunderstood, the people who were kicked off were kicked =
off
>> because their MTA processed the p=3Dreject, and acted accordingly.  =
Those
>> subscribers were not at fault, nor was their MTA.  The problem was =
with other
>> subscribers who sent email from a p=3Dreject, and those are the ones =
that
>> should be removed.
>=20
> Which means everyone with a yahoo.com address, among others.

Also Paypal.

I use gmail, so those messages are not rejected (at least yet), but they =
do go in the spam folder.

Can=92t we stop the mechanism that kicks out people after we get a few =
rejections from them?  Or at least make it more forgiving (like =
requiring a lot of rejections or no non-rejections over a long enough =
period of time)?

Yoav=

--Apple-Mail=_377BC529-5D52-4B2B-9901-8053F676FC04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Sep 24, 2014, at 5:22 PM, Derek =
Atkins <derek@ihtfp.com> =
wrote:

Michael Richardson <mcr+ietf@sandelman.ca> =
writes:

Eliot Lear <lear@cisco.com> =
wrote:
To answer your question as to =
whether there are best practices, not that
I am aware.  Here's =
at least a start at a suggested approach, if it =
helps.

1. Reinstate the =
individuals immediately;
2. Inform them of the problem, including =
when they were disabled;
3. Provide an explanation as to why it =
happened; and
4. Point them at the mail =
archive.

Others?

Unless I misunderstood, the =
people who were kicked off were kicked off
because their MTA =
processed the p=3Dreject, and acted accordingly. =
 Those
subscribers were not at fault, nor was their MTA. =
 The problem was with other
subscribers who sent email from a =
p=3Dreject, and those are the ones that
should be =
removed.

Which means everyone with a yahoo.com address, among =
others.

Also =
Paypal.

I use gmail, so those messages are not =
rejected (at least yet), but they do go in the spam =
folder.

Can=92t we stop the mechanism that =
kicks out people after we get a few rejections from them?  Or at =
least make it more forgiving (like requiring a lot of rejections or no =
non-rejections over a long enough period of =
time)?

Yoav=

--Apple-Mail=_377BC529-5D52-4B2B-9901-8053F676FC04--


From nobody Wed Sep 24 08:37:20 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37851A0142; Wed, 24 Sep 2014 08:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.787
X-Spam-Level: 
X-Spam-Status: No, score=-7.787 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 J3W4JpbDtDCs; Wed, 24 Sep 2014 08:37:14 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35AE71A00FD; Wed, 24 Sep 2014 08:37:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411573034; x=1443109034; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=BjF1UEm8kcy6vcgWui0xGpUc2GLzO3lOsvL6KnNa+94=; b=HHZ7Dk6gl2EKQTv8W7B+x2Fa2H43MBZ+NM6j4sPe8Te5qsd/cQEY1BGp 0zk9kWizLzE3sJhcylxhb9jhMi5uIXpaqgf8N1u1+epGb9Kl0Jz8UZcuH OwzTAJH2Gz+/pxkJ0DhDFpzRp4OSSy8o6GgoHxz8dd4x13XYrielqqjV/ w=;
X-IronPort-AV: E=McAfee;i="5600,1067,7570"; a="75383379"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Sep 2014 08:37:13 -0700
X-IronPort-AV: E=Sophos;i="5.04,589,1406617200"; d="scan'208";a="742527648"
Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Sep 2014 08:37:13 -0700
Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 24 Sep 2014 08:37:13 -0700
Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 24 Sep 2014 08:37:12 -0700
Message-ID: <5422E514.8070700@qti.qualcomm.com>
Date: Wed, 24 Sep 2014 10:36:52 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: The IESG , WG Chairs 
Subject: HEADS UP: Default notification list change
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/ScNrF_XQ6KkHPbAaNOMs7gENSVM
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 15:37:16 -0000

IESG/Chairs,

I want to give you a heads up about a small change in the datatracker 
that's getting deployed next week that may have surprising implications 
if you're not aware of it.

IESG: As we discussed, we're changing the default notification list for 
*new* documents coming into the tracker from 
"draft-foo-bar@tools.ietf.org" to "draft-foo-bar.all@tools.ietf.org", 
meaning that the WG will get Cc'ed on notifications and IESG Evaluation 
unless you change it. The expectation is that things will operate just 
as they do today (i.e., that it is between you and your chairs whether 
you want this stuff Cc'ed to the WG), but that when you forget to check, 
you will accidentally be sending more mail than you intended to the WG 
instead of less.

Chairs: This field gets populated at document adoption time, and you 
have the ability to edit it. Please consult with your AD about whether 
you want to edit the WG out of the field.

Again, keep in mind that this only changes the *default* list, and it 
only changes it for *newly* added documents. Even so, we want to avoid 
astonishment.

Your IESG tools liaison,

pr

-- 
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478


From nobody Wed Sep 24 08:54:45 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88AD1A0149; Wed, 24 Sep 2014 08:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.787
X-Spam-Level: 
X-Spam-Status: No, score=-7.787 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 M8vRyVthSXbL; Wed, 24 Sep 2014 08:54:39 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3161A0115; Wed, 24 Sep 2014 08:54:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411574079; x=1443110079; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=LwJg0937xwcSruxaSfxKWv3xexlABzG5sZLaeDwDqEo=; b=xhdSwEnoPoVf10ICqD8GBQWV9mc4mfY6Vyx24iNkCyil2jsFYywSBNX9 hbVDnYBhKnxlnchLY8EP29uEJxecPq0DHJQAWpl5godjiDPD4w1hsSdgf gWjUgSJEqcIETYDs9BdpCiGmADyEprX67cUU/pEc1jobZ6TzhH1K2AymZ Y=;
X-IronPort-AV: E=McAfee;i="5600,1067,7570"; a="74770048"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Sep 2014 08:54:39 -0700
X-IronPort-AV: E=Sophos;i="5.04,589,1406617200"; d="scan'208";a="757021518"
Received: from nasanexhc01.na.qualcomm.com ([10.46.57.53]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Sep 2014 08:54:39 -0700
Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by NASANEXHC01.na.qualcomm.com (10.46.57.53) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 24 Sep 2014 08:54:38 -0700
Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 24 Sep 2014 08:54:38 -0700
Message-ID: <5422E93C.8010407@qti.qualcomm.com>
Date: Wed, 24 Sep 2014 10:54:36 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: The IESG , WG Chairs 
Subject: Re: HEADS UP: Default notification list change
References: <5422E514.8070700@qti.qualcomm.com>
In-Reply-To: <5422E514.8070700@qti.qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/r2MqrdYH69kCmgA5-EvrpLo-Jzw
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 15:54:41 -0000

Can't even type straight:

On 9/24/14 10:36 AM, Pete Resnick wrote:
> As we discussed, we're changing the default notification list for 
> *new* documents coming into the tracker from 
> "draft-foo-bar@tools.ietf.org" to "draft-foo-bar.all@tools.ietf.org"

*and the WG list*.

(.all doesn't include the WG.)

Read what I mean, not what I write.

pr

-- 
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478


From nobody Wed Sep 24 09:06:27 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678C51A00E9; Wed, 24 Sep 2014 09:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.229
X-Spam-Level: 
X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.786, SPF_SOFTFAIL=0.665] autolearn=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 ATzPqiVjFDrp; Wed, 24 Sep 2014 09:06:22 -0700 (PDT)
Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id F2B631A00DA; Wed, 24 Sep 2014 09:06:21 -0700 (PDT)
Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 97610A442A4; Wed, 24 Sep 2014 18:06:19 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 8C92BA442A2; Wed, 24 Sep 2014 18:06:19 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 24 Sep 2014 18:06:19 +0200
Received: from [10.193.71.69] ([10.193.71.69]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 24 Sep 2014 18:06:18 +0200
Message-ID: <5422EBF9.7040303@orange.com>
Date: Wed, 24 Sep 2014 18:06:17 +0200
From: Julien Meuric 
Organization: Orange
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Pete Resnick 
Subject: Re: HEADS UP: Default notification list change
References: <5422E514.8070700@qti.qualcomm.com> <5422E93C.8010407@qti.qualcomm.com>
In-Reply-To: <5422E93C.8010407@qti.qualcomm.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Sep 2014 16:06:18.0538 (UTC) FILETIME=[79BB10A0:01CFD811]
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/K3qUQZ5hmetKhte5Jf4bhm5nwck
Cc: WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 16:06:23 -0000

That's what I tell my compiler every time! ;-)

Thanks for the update,

Julien


Sep. 24, 2014 - Pete Resnick:
>
> Read what I mean, not what I write.


From nobody Wed Sep 24 11:10:02 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5DD1A0312; Wed, 24 Sep 2014 11:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.787
X-Spam-Level: 
X-Spam-Status: No, score=-7.787 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 XggvZBzhb9g1; Wed, 24 Sep 2014 11:09:58 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D141A0311; Wed, 24 Sep 2014 11:09:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411582198; x=1443118198; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=G9VMAY32ZlpOyPJeyRTytYF+Jfa5Qssri2pVPPUgmFM=; b=tiKk4liGqu37wZac0U4Z2aq/lngcBRO41R7XtIsUWUQ6VHiIgeiMkL8v 4lbzHf+P7Wrqyz5Egol48rBUwYLWHlEgIAspzO8HTX0XWfiZL6NfWBikC 3XAEgRgW3WKy91Jcx0ynmsxII+TpIWeBBbssTBtMux5vURkDE/jsS5nfv k=;
X-IronPort-AV: E=McAfee;i="5600,1067,7571"; a="74777515"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Sep 2014 11:09:57 -0700
X-IronPort-AV: E=Sophos;i="5.04,590,1406617200"; d="scan'208";a="717110435"
Received: from nasanexhc03.na.qualcomm.com ([10.46.200.142]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Sep 2014 11:09:57 -0700
Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by NASANEXHC03.na.qualcomm.com (10.46.200.142) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 24 Sep 2014 11:09:57 -0700
Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 24 Sep 2014 11:09:56 -0700
Message-ID: <542308F1.8020709@qti.qualcomm.com>
Date: Wed, 24 Sep 2014 13:09:53 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: The IESG , WG Chairs 
Subject: Re: HEADS UP: Default notification list change
References: <5422E514.8070700@qti.qualcomm.com>
In-Reply-To: <5422E514.8070700@qti.qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/hHlN53IZ4T2hVZ3DXL_xy3pa9yw
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 18:09:59 -0000

OK, I seem to have confused some folks, so let me try one last time to 
unmuddle. My apologies for my broken brain:

@tools.ietf.org is the authors.
.all@tools.ietf.org is the authors and the chairs (and the AD, 
once it starts IESG processing).

The default notification list for WG documents is currently 
"-chairs@tools.ietf.org, @tools.ietf.org".

The default notification list for WG documents is changing to 
".all@tools.ietf.org, @ietf.org".

Also, when a shepherd is assigned, the shepherd's email address is added 
to the list.

I hope that makes more sense.

pr

-- 
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478


From nobody Wed Sep 24 11:11:49 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A041A00DA for ; Wed, 24 Sep 2014 11:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level: 
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
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 oLmfCCzviGMx for ; Wed, 24 Sep 2014 11:11:46 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 E062E1A0242 for ; Wed, 24 Sep 2014 11:11:45 -0700 (PDT)
Received: from unnumerable.local (pool-173-57-97-85.dllstx.fios.verizon.net [173.57.97.85]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8OIBirh068920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Wed, 24 Sep 2014 13:11:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-97-85.dllstx.fios.verizon.net [173.57.97.85] claimed to be unnumerable.local
Message-ID: <54230960.4080301@nostrum.com>
Date: Wed, 24 Sep 2014 13:11:44 -0500
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: wgchairs@ietf.org
Subject: Re: HEADS UP: Default notification list change
References: <5422E514.8070700@qti.qualcomm.com> <542308F1.8020709@qti.qualcomm.com>
In-Reply-To: <542308F1.8020709@qti.qualcomm.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/uNN_RS5KY_-mSnsejV5BNGQ-Bqc
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 18:11:47 -0000

On 9/24/14 1:09 PM, Pete Resnick wrote:
> OK, I seem to have confused some folks, so let me try one last time to 
> unmuddle. My apologies for my broken brain:
>
> @tools.ietf.org is the authors.
> .all@tools.ietf.org is the authors and the chairs (and the 
> AD, once it starts IESG processing).
>
> The default notification list for WG documents is currently 
> "-chairs@tools.ietf.org, @tools.ietf.org".
>
> The default notification list for WG documents is changing to 
> ".all@tools.ietf.org, @ietf.org".
>
> Also, when a shepherd is assigned, the shepherd's email address is 
> added to the list.
>
> I hope that makes more sense.
Also, that's just what the Notification gets set to by default. You can 
always change it.
>
> pr
>


From nobody Wed Sep 24 11:22:54 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646BA1A0319 for ; Wed, 24 Sep 2014 11:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 Ct_CL-HKfyLU for ; Wed, 24 Sep 2014 11:22:50 -0700 (PDT)
Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566E01A02D9 for ; Wed, 24 Sep 2014 11:22:50 -0700 (PDT)
Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-02v.sys.comcast.net with comcast id v6Lk1o00254zqzk016NpUM; Wed, 24 Sep 2014 18:22:49 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-11v.sys.comcast.net with comcast id v6No1o00P3Ge9ey016NoHK; Wed, 24 Sep 2014 18:22:49 +0000
Message-ID: <54230BF8.1050204@alum.mit.edu>
Date: Wed, 24 Sep 2014 14:22:48 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: wgchairs@ietf.org
Subject: Re: HEADS UP: Default notification list change
References: <5422E514.8070700@qti.qualcomm.com> <542308F1.8020709@qti.qualcomm.com>
In-Reply-To: <542308F1.8020709@qti.qualcomm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411582969; bh=6yJyDUzkbznfF8rL8/0muHMQp0I+3vCT4sJifHicxnI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aRvrNiG3OzPmizFeH/O2ZVNjf1JLgfcKhCFSMXoUN9LDGqszL2ufH0/GjXDZbGFJQ fFQW+CxktkzUd+kmFz/ES0rH8ruE0D/QkkiA6o2T5j2YlH5F58LFSJp5WGYcobfxCP uJUO52NFBbRroWXBR/uFhrkeWrxbaLZpPxSdXKSRD/PpyFvEg8TXgClGf6j+nBBb2k ufPf5JJACN4LUlwfWosGLnvxnyIMXDq1MgR2DPMBrN8xBGB/q7dYVK8ylrdtSsu3JV sCRB/M8R/D0FVnq1UhYku6bhC5JW8qolyuBFB54/7mQ+YEkrO0/5KcQmhDpysD32N9 6wUF7BiNjrKTQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/YwMpaIy7lRbNSkvOTDihSEKVH7Q
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 18:22:51 -0000

Pete,

Below is clear as far as it goes, but it leaves me with two questions:

- You say "the default notification list", which implies to me that this 
can be overridden. How? Can I see and edit this definition somewhere?

- how is this notification list referenced for sending stuff? Is there 
some foo such that .foo@tools.ietf.org references this 
notification list?

	Thanks,
	Paul

On 9/24/14 2:09 PM, Pete Resnick wrote:
> OK, I seem to have confused some folks, so let me try one last time to
> unmuddle. My apologies for my broken brain:
>
> @tools.ietf.org is the authors.
> .all@tools.ietf.org is the authors and the chairs (and the AD,
> once it starts IESG processing).
>
> The default notification list for WG documents is currently
> "-chairs@tools.ietf.org, @tools.ietf.org".
>
> The default notification list for WG documents is changing to
> ".all@tools.ietf.org, @ietf.org".
>
> Also, when a shepherd is assigned, the shepherd's email address is added
> to the list.
>
> I hope that makes more sense.
>
> pr
>


From nobody Wed Sep 24 11:28:33 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0ED1A0329; Wed, 24 Sep 2014 11:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 q0ALBSWDcutT; Wed, 24 Sep 2014 11:28:24 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4688F1A031C; Wed, 24 Sep 2014 11:28:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: IETF Agenda 
To: Working Group Chairs 
Subject: REMINDER - IETF 91 Working Group/BOF/IRTF Scheduling Cutoff this Friday
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140924182824.27116.90503.idtracker@ietfa.amsl.com>
Date: Wed, 24 Sep 2014 11:28:24 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/-DQ4rvReOxfeUKleODu6Pn7KgfI
Cc: irsg@irtf.org
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: IETF Agenda 
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 18:28:27 -0000

-----------------------------------------------------------------
91st IETF – Honolulu, HI, USA
Meeting Dates: November 9 - 14, 2014
-----------------------------------------------------------------

The cutoff for session requests and BoF submissions is this Friday, September 26 at UTC 23:59.

NOTE: Please ensure your list of conflicts is complete and up to date prior to submitting your session request.

The milestones and deadlines for scheduling-related activities are as follows:
Cut-off dates are subject to change.


•	2014-09-26 (Friday): Cut-off date for requests to schedule Working Group meetings at UTC 23:59. To request a Working Group session, use the IETF Meeting Session Request Tool.
•	2014-09-26 (Friday): Cut-off date for BOF proposal requests to Area Directors at UTC 23:59. To request a BOF, please see instructions on Requesting a BOF.
•	2014-10-03 (Friday): Cut-off date for Area Directors to approve BOFs at UTC 23:59.
•	2014-10-10 (Friday): Preliminary agenda published for comment.
•	2014-10-13 (Monday): Cut-off date for requests to reschedule Working Group and BOF meetings UTC 23:59.
•	2014-10-17 (Friday): Final agenda to be published.
•	2014-10-27 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.
•	2014-11-03 (Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.
•	2014-12-05 (Friday): Proceedings submission cutoff date by UTC 23:59, upload using IETF Meeting Materials Management Tool.
•	2014-12-26 (Friday): Proceedings submission corrections cutoff date by UTC 23:59, upload using IETF Meeting Materials Management Tool.


===============================================================
For your convenience, comprehensive information on requesting meeting sessions is presented below:

1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions.  The URL for the tool is:

https://datatracker.ietf.org/secr/sreq/

Instructions for using the tool are available at:

http://www.ietf.org/wg/request-tool-instructions.html

If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org.  If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s).

Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s).

When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line.

2. BOFs will NOT be scheduled unless the Area Director approves the BOF. The proponents behind a BOF need to contact a relevant Area Director, preferably well in advance of the BOF approval deadline date. The AD needs to have the full name of the BOF, its acronym, suggested names of chairs, an agenda, full description of the BOF and the information covered in item 4. Please read RFC 5434 for instructions on how to drive a successful BOF effort. The approval depends on, for instance, Internet-Drafts and list discussion on the suggested topic. BOF agenda requests, if approved, will be submitted to the IETF Secretariat by the ADs.

3. A Working Group may request either one or two sessions.  If your Working Group requires more than two sessions, then your request must be approved by an Area Director.  Additional sessions will be assigned, based on availability, after Monday, October 13th, 2014, the cut-off date for requests to reschedule a session.

4. You MUST provide the following information before a Working Group or BOF session will be scheduled:

a. Working Group or BOF full name with acronym in brackets: 
b. AREA under which Working Group or BOF appears:
c. CONFLICTS you wish to avoid, please be as specific as possible:
d. Expected Attendance:
e. Special requests:
f. Number of sessions:
g. Length of session: 1 hour, 1.5 hours, 2 hours, 2.5 hours
       		
For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt).

===============================================================

Submitting Session Agendas

For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible.  Draft Working Group agendas are due Monday, October 27th, 2014 at UTC 23:59.  Revised Working Group agendas are due no later than Monday, November 3rd, 2014 at UTC 23:59.  The proposed agenda for a BOF session should be submitted along with your request for a session.  Please be sure to copy your Area Director on that message.

Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting.  If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved.

The URL for the tool is:

https://datatracker.ietf.org/secr/proceedings/

Additional information about this tool is available at:

http://www.ietf.org/wg/meeting-materials.html

Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" webpage as soon as they are submitted.

The URL for the "IETF 91 Meeting Materials" Web page is:

https://datatracker.ietf.org/meeting/91/materials.html

If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool."  The same User ID and password will work for both tools.  If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved.  If you require assistance in using either tool, or wish to report a bug, then please send a message to:
ietf-action@ietf.org.

===============================================================
For your convenience please find a list of the IETF Area Directors with their e-mail addresses below:

IETF Chair 
Jari Arkko 

Applications Area (app)
Barry Leiba 
Pete Resnick 

Internet Area (int) 
Brian Haberman  
Ted Lemon 

Operations & Management Area (ops) 
Benoit Claise  
Joel Jaeggli 

Real-time Applications and Infrastructure Area (rai)
Richard Barnes   
Alissa Cooper   

Routing Area (rtg) 
Alia Atlas 
Adrian Farrel   

Security Area (sec) 
Stephen Farrell 
Kathleen Moriarty   

Transport Area (tsv) 
Spencer Dawkins  
Martin Stiemerling  

 ===========================================================
90th IETF Meeting Attendance Numbers

6lo - 66
6tisch - 63
abfab – 42
ace - 70
actn (BoF) - 114
alto  - 38
appsawg/apparea - 157
aqm - 50
avtcore - 49
avtext - 40
bfd - 46
bmwg - 24
ccamp - 42
ccamp (2nd session) - 44
cdni – 35
cfrg - 80
clue – 23
clue (2nd session) - 21
core - 64
core (2nd session) – 31
dane - 158
dart - 57
dclcrg (RG BoF) - 37
dhc - 44
dice - 58
dime - 17
dispatch - 69
dmm - 30
dmm (2nd session) - 28
dnsop - 149
dnssd - 63
dtnwg (BoF) - 85
ecrit - 28
forces - 76
grow - 45
homenet - 136
httpauth - 56
httpbis - Not Provided
httpbis (2nd session) - Not Provided
i2rs - 119
ianaplan - 170
icnrg (RG) - 90
idr - 72
intarea (AG) - 94
ippm - 44
ipsecme - 37
IRTF Open Meeting - 87
isis - 42
jose - 41
kitten - 16
l2vpn - 96
l3vpn - 50
lisp - 24
lmap - 36
lwig - 23
manet - 17
mboned - 16
mif – 49
mile - 32
mmusic - 56
mmusic (2nd session) - 42
mpls - 123
mpls (2nd session) - 68
mptcp - 73
netconf - 94
netext - 26
netmod - 106
nfsv4 - 17
nmrg (RG) - 56
ntp (combined with tictoc) - 30
nvo3 - 102
oauth - 44
opsawg/opsarea - 79
ospf - 42
paws – 23
pce - 87
pim - 21
ppsp - 14
precis - 27
pwe3 - 31
radext - 11
rfcform - 66
rmcat - 52
rmcat (2nd session) - 31
roll - 33
rtcweb - 101
rtcweb (2nd session) - 87
rtgarea (AG) - 150
rtgwg - 64
saag (AG) - 168
sacm - 40
sacm (2nd session) - 29
scim - 28
sdnrg (RG) – 193
sfc - 248
sidr - 60
sipcore - 34
siprec - 11
softwire - 54
spring - 157
stir - 43
straw - 23
sunset4 - 75
taps - 107
tcpinc - 96
tcpm - 46
tictoc (combined with ntp) - 30
tls - 139
tls (2nd session) - 94
tram - 30
trans - 44
trill - 19
tsvwg - 75
tsvwg (2nd session) - 76
ucan (BoF) - 159
uta - 102
urnbis - 29
v6ops - 198
v6ops (2nd session) – 62
vnfpool (BoF) - 180
weirds - 60
xrblock - 25


From nobody Wed Sep 24 11:41:44 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CB91A02DD for ; Wed, 24 Sep 2014 11:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Level: 
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham
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 pHoEfM9Fp_ul for ; Wed, 24 Sep 2014 11:41:41 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 25EBD1A00EF for ; Wed, 24 Sep 2014 11:41:40 -0700 (PDT)
Received: from unnumerable.local (pool-173-57-97-85.dllstx.fios.verizon.net [173.57.97.85]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8OIfdbm071373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Wed, 24 Sep 2014 13:41:40 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-97-85.dllstx.fios.verizon.net [173.57.97.85] claimed to be unnumerable.local
Message-ID: <54231063.1010704@nostrum.com>
Date: Wed, 24 Sep 2014 13:41:39 -0500
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: wgchairs@ietf.org
Subject: Re: HEADS UP: Default notification list change
References: <5422E514.8070700@qti.qualcomm.com> <542308F1.8020709@qti.qualcomm.com> <54230BF8.1050204@alum.mit.edu>
In-Reply-To: <54230BF8.1050204@alum.mit.edu>
Content-Type: multipart/alternative; boundary="------------000501010202060809060102"
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/6eS3eX8oy5bqExXUOebwdl9c1Ag
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 18:41:43 -0000

This is a multi-part message in MIME format.
--------------000501010202060809060102
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit


On 9/24/14 1:22 PM, Paul Kyzivat wrote:
> Pete,
>
> Below is clear as far as it goes, but it leaves me with two questions:
>
> - You say "the default notification list", which implies to me that 
> this can be overridden. How? Can I see and edit this definition 
> somewhere?
You can see it on the Document's main page.

Look at  for 
example at the line that says:
Send notices to:     stir-chairs@tools.ietf.org, 
draft-ietf-stir-threats@tools.ietf.org

At , you'll see
Send notices to:     No addresses provided

Addresses will get added to that automatically when you pubreq the doc. 
With the upcoming change, when you make a doc a WG item, the group's 
list will automatically get added.

Addresses can be manually added or removed at any time. Right now, only 
the secretariat and ADs can edit the field though. It would be 
reasonable, IMHO, to let wg chairs do that too (you'd see a pencil, 
similar to what you see now for the shepherd or the intended status.)


>
> - how is this notification list referenced for sending stuff? Is there 
> some foo such that .foo@tools.ietf.org references this 
> notification list?
This field gets used internally in the tracker to add addresses to the 
messages it sends when document events happen (such states change, 
ballots are entered, etc.)

There is no @tools.ietf.org alias that refers directly to it.
>
>     Thanks,
>     Paul
>
> On 9/24/14 2:09 PM, Pete Resnick wrote:
>> OK, I seem to have confused some folks, so let me try one last time to
>> unmuddle. My apologies for my broken brain:
>>
>> @tools.ietf.org is the authors.
>> .all@tools.ietf.org is the authors and the chairs (and the AD,
>> once it starts IESG processing).
>>
>> The default notification list for WG documents is currently
>> "-chairs@tools.ietf.org, @tools.ietf.org".
>>
>> The default notification list for WG documents is changing to
>> ".all@tools.ietf.org, @ietf.org".
>>
>> Also, when a shepherd is assigned, the shepherd's email address is added
>> to the list.
>>
>> I hope that makes more sense.
>>
>> pr
>>
>


--------------000501010202060809060102
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    On 9/24/14 1:22 PM, Paul Kyzivat wrote:

    
    Pete,
      

      

      Below is clear as far as it goes, but it leaves me with two
      questions:
      

      

      - You say "the default notification list", which implies to me
      that this can be overridden. How? Can I see and edit this
      definition somewhere?
      

    
    You can see it on the Document's main page.

    

    Look at
    <http://datatracker.ietf.org/doc/draft-ietf-stir-threats/> for
    example at the line that says:

    
    Send notices to: ��� stir-chairs@tools.ietf.org,
    draft-ietf-stir-threats@tools.ietf.org 

    

    At
    <http://datatracker.ietf.org/doc/draft-ietf-clue-framework/>,
    you'll see

    
    Send notices to: ��� No addresses provided 

    

    Addresses will get added to that automatically when you pubreq the
    doc. With the upcoming change, when you make a doc a WG item, the
    group's list will automatically get added.

    

    Addresses can be manually added or removed at any time. Right now,
    only the secretariat and ADs can edit the field though. It would be
    reasonable, IMHO, to let wg chairs do that too (you'd see a pencil,
    similar to what you see now for the shepherd or the intended status.)

    

    

    
      

      - how is this notification list referenced for sending stuff? Is
      there some foo such that <docname>.foo@tools.ietf.org
      references this notification list?
      

    
    This field gets used internally in the tracker to add addresses to
    the messages it sends when document events happen (such states
    change, ballots are entered, etc.)

    

    There is no @tools.ietf.org alias that refers directly to it.

    
      

      ����Thanks,
      

      ����Paul
      

      

      On 9/24/14 2:09 PM, Pete Resnick wrote:
      

      OK, I seem to have confused some folks, so
        let me try one last time to
        

        unmuddle. My apologies for my broken brain:
        

        

        <docname>@tools.ietf.org is the authors.
        

        <docname>.all@tools.ietf.org is the authors and the chairs
        (and the AD,
        

        once it starts IESG processing).
        

        

        The default notification list for WG documents is currently
        

        "<wg>-chairs@tools.ietf.org,
        <docname>@tools.ietf.org".
        

        

        The default notification list for WG documents is changing to
        

        "<docname>.all@tools.ietf.org, <wg>@ietf.org".
        

        

        Also, when a shepherd is assigned, the shepherd's email address
        is added
        

        to the list.
        

        

        I hope that makes more sense.
        

        

        pr
        

        

      
      

    
    

  


--------------000501010202060809060102--


From nobody Wed Sep 24 13:27:44 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345A61A19E3 for ; Wed, 24 Sep 2014 13:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 M9FT2-krcbGL for ; Wed, 24 Sep 2014 13:27:41 -0700 (PDT)
Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3313D1A07BE for ; Wed, 24 Sep 2014 13:27:41 -0700 (PDT)
Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-09v.sys.comcast.net with comcast id v8T11o0064tLnxL018TfDr; Wed, 24 Sep 2014 20:27:39 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-02v.sys.comcast.net with comcast id v8Te1o00U3Ge9ey018Tf4H; Wed, 24 Sep 2014 20:27:39 +0000
Message-ID: <5423293A.4080802@alum.mit.edu>
Date: Wed, 24 Sep 2014 16:27:38 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: wgchairs@ietf.org
Subject: Re: HEADS UP: Default notification list change
References: <5422E514.8070700@qti.qualcomm.com> <542308F1.8020709@qti.qualcomm.com> <54230BF8.1050204@alum.mit.edu> <54231063.1010704@nostrum.com>
In-Reply-To: <54231063.1010704@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411590459; bh=Qw/qsB+bUD1T+ye0fKTEMp1tcaF7fiFP4XjP9KLPCjU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OJSDG5Wh/uWRayDIcpV6g37WTvJfrTqF63FVcIMiAjhNSeB+EM+2m2cAXx5iHXVMn E2Qm3Q+/cIkDKFZANHOCBtSTrlcnUNMZe3whWzytPh2qYR6bTAs+T0OeyI550o96UE rYlKDv0w9hCCuT/5Jzfy6q8XjzpwiLlYdNZzYQymwxdanwHmv38FlL8R6blELKyNOa 4NhtWosJw8uEMi4FxqOx1KUMyWpKd4CxfRwpZDh/DIVnqhl2uJ1jnBnobX7te9WeiW 29iO8tMu8aJnoE7WCC/qSxS0EoGhPuhz6660uaoepPFzZExdeMrJgc8+OVcr/mzM4H PXurk8gNHtr8Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/tCTtU8WNI2y2B1o64TQzijF0ZDs
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 20:27:43 -0000

On 9/24/14 2:41 PM, Robert Sparks wrote:
>
> On 9/24/14 1:22 PM, Paul Kyzivat wrote:
>> Pete,
>>
>> Below is clear as far as it goes, but it leaves me with two questions:
>>
>> - You say "the default notification list", which implies to me that
>> this can be overridden. How? Can I see and edit this definition
>> somewhere?
> You can see it on the Document's main page.
>
> Look at  for
> example at the line that says:
> Send notices to: stir-chairs@tools.ietf.org,
> draft-ietf-stir-threats@tools.ietf.org
>
> At , you'll see
> Send notices to:     No addresses provided

I never knew that - never noticed.

> Addresses will get added to that automatically when you pubreq the doc.
> With the upcoming change, when you make a doc a WG item, the group's
> list will automatically get added.
>
> Addresses can be manually added or removed at any time. Right now, only
> the secretariat and ADs can edit the field though. It would be
> reasonable, IMHO, to let wg chairs do that too (you'd see a pencil,
> similar to what you see now for the shepherd or the intended status.)

So for now chairs have no control over this. So I guess it doesn't 
matter much to us. :-)

	Thanks,
	Paul

>> - how is this notification list referenced for sending stuff? Is there
>> some foo such that .foo@tools.ietf.org references this
>> notification list?
> This field gets used internally in the tracker to add addresses to the
> messages it sends when document events happen (such states change,
> ballots are entered, etc.)
>
> There is no @tools.ietf.org alias that refers directly to it.
>>
>>     Thanks,
>>     Paul
>>
>> On 9/24/14 2:09 PM, Pete Resnick wrote:
>>> OK, I seem to have confused some folks, so let me try one last time to
>>> unmuddle. My apologies for my broken brain:
>>>
>>> @tools.ietf.org is the authors.
>>> .all@tools.ietf.org is the authors and the chairs (and the AD,
>>> once it starts IESG processing).
>>>
>>> The default notification list for WG documents is currently
>>> "-chairs@tools.ietf.org, @tools.ietf.org".
>>>
>>> The default notification list for WG documents is changing to
>>> ".all@tools.ietf.org, @ietf.org".
>>>
>>> Also, when a shepherd is assigned, the shepherd's email address is added
>>> to the list.
>>>
>>> I hope that makes more sense.
>>>
>>> pr
>>>
>>
>


From nobody Wed Sep 24 18:35:26 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1351A1BFC for ; Wed, 24 Sep 2014 18:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 BjNHC8_C7nGN for ; Wed, 24 Sep 2014 18:35:23 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31831A6EFE for ; Wed, 24 Sep 2014 18:35:22 -0700 (PDT)
X-AuditID: 1209190f-f79aa6d000005b45-e9-542371590b96
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 11.67.23365.95173245; Wed, 24 Sep 2014 21:35:21 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s8P1ZKKK029648; Wed, 24 Sep 2014 21:35:21 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8P1ZIed031545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Sep 2014 21:35:20 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8P1ZITa028989; Wed, 24 Sep 2014 21:35:18 -0400 (EDT)
Date: Wed, 24 Sep 2014 21:35:18 -0400 (EDT)
From: Benjamin Kaduk 
To: Yoav Nir 
Subject: Re: best practices for dealing with DMARC fallout on IETF lists
In-Reply-To: 
Message-ID: 
References:  <54224924.6080808@cisco.com>  <54224DB1.9030607@cisco.com> <11835.1411566784@sandelman.ca>  
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT140sVA4xmD5Z2eL//imMFkuPfWBy YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDLuzHjMWNDAUrH59WmmBsaJzF2MnBwSAiYS TycegLLFJC7cW8/WxcjFISQwm0ni8eGVLBDORkaJJaeWskI4h5gkDr3awQ7hNDBKnH3exwbS zyKgLbHs20UmEJtNQEVi5puNYHERASWJw1e+gu1gFlCUWL92EiuILSzgIXHzzhKwOKeArcTJ 3z/A4rwCjhL9i45A3bGSSWL2i6Ngg0QFdCRW75/CAlEkKHFy5hMWiKFaEsunb2OZwCg4C0lq FpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbomermZJXqpKaWbGEHhyinJv4Px20GlQ4wC HIxKPLwe/sohQqyJZcWVuYcYJTmYlER5fXKBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4NRyA crwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErxOBUCNgkWp6akVaZk5 JQhpJg5OkOE8QMMrQGp4iwsSc4sz0yHypxiNOVqa3vYycazr/NbPJMSSl5+XKiXOywFSKgBS mlGaBzcNlnJeMYoDPSfMGwlSxQNMV3DzXgGtYgJadf+4PMiqkkSElFQDo6Im/4EKM82l52qN Laef6hM2UV934eVn3uOhUyIOPBWWuGcTKyLN4/b4RUYHV5yk6L2jK54eqvvabf1np5lbWpJQ v+sSc6+KHOm1Ub+6P3LVnb10JDyxVsh6bsGEOb3hu69trkze4z7zlZlDRKnXQjnetJtH+rWF HD3SKsJV5x6fWPOb29hNiaU4I9FQi7moOBEAyL/ZHhQDAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/rHRnke-2mqTWwiDX1AzmFkmo2-8
Cc: WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Sep 2014 01:35:24 -0000

On Wed, 24 Sep 2014, Yoav Nir wrote:

>
>
> Can't we stop the mechanism that kicks out people after we get a few
> rejections from them?  Or at least make it more forgiving (like
> requiring a lot of rejections or no non-rejections over a long enough
> period of time)?

My understanding is that mailman 2.1.18 (released early May 2014) includes
features for handling DMARC fallout.

We appear to be running 2.1.15 for the IETF mailman instance, according to
the footer on the admin pages.

-Ben


From nobody Wed Sep 24 18:46:44 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D2B1A6F04 for ; Wed, 24 Sep 2014 18:46:43 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=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 xog3ntui8iHx for ; Wed, 24 Sep 2014 18:46:42 -0700 (PDT)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164A51A6EFE for ; Wed, 24 Sep 2014 18:46:42 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id v10so8452241pde.34 for ; Wed, 24 Sep 2014 18:46:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LQPH8ycxXrR/mrxppYBqq9j2bQDrJMRTkhGytTzAd1k=; b=fKlEj3WLBVNfy2bhibDIa86uiQbrS+COwK24/KlH02gEBtCGb2UBtCOBxJGhjRKicX N2jhDNItI5c8fmdhbYR03YU2VD8YhnRN1THSB1hAc/ahAPNX6vwYEmYBmFIrW7nWSbZT klWQp2WlzRNdTxF2n6Bklen528WXkApKHz8gcnhpMDgdaIvXP7lzD+46TI81fdUJw8aN RHKQtptDOuNKNDyW0wpnEZhJFiSCNeeR0PICTK7qT1TEYczYGPpeSounZR81zZBay5Jw BlVSQFlru9h8FX3CEOZI99xb9V8t+0lzxGILpOe0u/7SOVB+D4CN6SJGeN6cw0CTcVRe BQWQ==
X-Received: by 10.68.209.169 with SMTP id mn9mr13709062pbc.37.1411609601723; Wed, 24 Sep 2014 18:46:41 -0700 (PDT)
Received: from [192.168.178.23] (163.199.69.111.dynamic.snap.net.nz. [111.69.199.163]) by mx.google.com with ESMTPSA id gj10sm499100pbd.50.2014.09.24.18.46.37 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Sep 2014 18:46:40 -0700 (PDT)
Message-ID: <54237403.5040602@gmail.com>
Date: Thu, 25 Sep 2014 13:46:43 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Yoav Nir 
Subject: Re: [BOFChairs] best practices for dealing with DMARC fallout on IETF lists
References:  <54224924.6080808@cisco.com>  <54224DB1.9030607@cisco.com> <11835.1411566784@sandelman.ca>  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/Ny3YD-rwNEKGMtzRjfmfOpGzrS0
Cc: Michael Richardson , WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Sep 2014 01:46:43 -0000

You can tune the bounce processing from the mailman admin page;
the tab is called "Bounce processing" ;-)

I've just applied these settings to a particular list:

Bounce score threshold 20.0 (user is less likely to be disabled)
Bounce info stale after 1  (bounce history is reset after 1 day)
You are disabled warnings 100 (user is highly unlikely to be auto-deleted=
)

That will, I hope, diminish the problem. But people who
bounce when they see p=3Dreject should be advised not to do
that (gmail doesn't, but it does quarantine which is already
a problem) and people who publish p=3Dreject should be advised
strongly not to do that, if they wish to join IETF lists with
the present version of mailman.

Unfortunately there's no option to fake the sender if and only
if the sender's domain publishes p=3Dreject. That would be nice.

Regards
   Brian

On 25/09/2014 02:50, Yoav Nir wrote:
> On Sep 24, 2014, at 5:22 PM, Derek Atkins  wrote:
>=20
>> Michael Richardson  writes:
>>
>>> Eliot Lear  wrote:
>>>> To answer your question as to whether there are best practices, not =
that
>>>> I am aware.  Here's at least a start at a suggested approach, if it =
helps.
>>>> 1. Reinstate the individuals immediately;
>>>> 2. Inform them of the problem, including when they were disabled;
>>>> 3. Provide an explanation as to why it happened; and
>>>> 4. Point them at the mail archive.
>>>> Others?
>>> Unless I misunderstood, the people who were kicked off were kicked of=
f
>>> because their MTA processed the p=3Dreject, and acted accordingly.  T=
hose
>>> subscribers were not at fault, nor was their MTA.  The problem was wi=
th other
>>> subscribers who sent email from a p=3Dreject, and those are the ones =
that
>>> should be removed.
>> Which means everyone with a yahoo.com address, among others.
>=20
> Also Paypal.
>=20
> I use gmail, so those messages are not rejected (at least yet), but the=
y do go in the spam folder.
>=20
> Can=E2=80=99t we stop the mechanism that kicks out people after we get =
a few rejections from them?  Or at least make it more forgiving (like req=
uiring a lot of rejections or no non-rejections over a long enough period=
 of time)?
>=20
> Yoav
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> _______________________________________________
> BOFChairs mailing list
> BOFChairs@ietf.org
> https://www.ietf.org/mailman/listinfo/bofchairs


From nobody Wed Sep 24 20:40:10 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A6E1A0164 for ; Wed, 24 Sep 2014 20:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.387
X-Spam-Level: 
X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 ZjvGd2a-fUPF for ; Wed, 24 Sep 2014 20:40:06 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 37D6D1A01E1 for ; Wed, 24 Sep 2014 20:40:05 -0700 (PDT)
X-AuditID: 12074422-f79436d000000c21-64-54238e957168
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 60.E2.03105.59E83245; Wed, 24 Sep 2014 23:40:05 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s8P3e4et022265; Wed, 24 Sep 2014 23:40:05 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8P3e2ml002210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Sep 2014 23:40:04 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8P3e2wv014589; Wed, 24 Sep 2014 23:40:02 -0400 (EDT)
Date: Wed, 24 Sep 2014 23:40:02 -0400 (EDT)
From: Benjamin Kaduk 
To: Brian E Carpenter 
Subject: Re: [BOFChairs] best practices for dealing with DMARC fallout on IETF lists
In-Reply-To: <54237403.5040602@gmail.com>
Message-ID: 
References:  <54224924.6080808@cisco.com>  <54224DB1.9030607@cisco.com> <11835.1411566784@sandelman.ca>   <54237403.5040602@gmail.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixG6noju1TznEYP50IYu2i/uYLP7vn8Lo wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGUsnrGFueAXb8Wz/j9sDYx93F2MnBwSAiYS 8+auY4KwxSQu3FvP1sXIxSEkMJtJouXqVEYIZyOjRPP7xVCZQ0wSu+duYYZwGhgl1l5ZzQLS zyKgLdF8dBMziM0moCIx881GNhBbRMBYorHrNCuIzSygKLF+7SQwW1ggTKJn9kqwek4BTYk/ fdfA4rwCjhL3515ngVhwjEli8qw+sANFBXQkVu+fwgJRJChxcuYTFoihWhLLp29jmcAoOAtJ ahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6pnq5mSV6qSmlmxjB4eqitIPx50GlQ4wC HIxKPLwe/sohQqyJZcWVuYcYJTmYlER5y8uAQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4NRyA crwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKEryFvUCNgkWp6akVaZk5 JQhpJg5OkOE8QMNze0CGFxck5hZnpkPkTzHqcqzr/NbPJMSSl5+XKiXOGwQySACkKKM0D24O LM28YhQHekuYtx6kigeYouAmvQJawgS05P5xeZAlJYkIKakGRjkGhwdNOyXbYs/si1wgkPP/ qlvG1o3yGy283XP2rnmhIPQ8vXJe20dOoRhXvul3b/m+Zln++uqFFQf4Vdev5DIpuXQl9ELU stJJy6+1HdiSaNv96OVL3ziZDRVh5nek37RZK221aWGd8riEO1z+xokPybv1L0+7lxi05Py3 VOuAkNz/68zFU5VYijMSDbWYi4oTAYgMh1sOAwAA
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/lcCpIiMSgpouBPXic7a5EVCKK1M
Cc: WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Sep 2014 03:40:08 -0000

On Wed, 24 Sep 2014, Brian E Carpenter wrote:

> You can tune the bounce processing from the mailman admin page;
> the tab is called "Bounce processing" ;-)
>
> I've just applied these settings to a particular list:
>
> Bounce score threshold 20.0 (user is less likely to be disabled)
> Bounce info stale after 1  (bounce history is reset after 1 day)

Thanks for pointing this out.  I dropped down the "bounce info stale"
value for kitten, which will in all likelihood prevent future issues for
us.

> You are disabled warnings 100 (user is highly unlikely to be auto-deleted)

This setting (and the related description text) seems to say that mailman
itself will be notifying members that their subscription is disabled.  So,
perhaps it is not necessary for the WG chairs to send additional
notification?  Perhaps it still is, though, as we can include dates and
the link to the archives.

> That will, I hope, diminish the problem. But people who
> bounce when they see p=reject should be advised not to do
> that (gmail doesn't, but it does quarantine which is already
> a problem) and people who publish p=reject should be advised
> strongly not to do that, if they wish to join IETF lists with
> the present version of mailman.
>
> Unfortunately there's no option to fake the sender if and only
> if the sender's domain publishes p=reject. That would be nice.

I really think that this is a question for the people who maintain the
mailman deployment for the IETF.  Among other things, upgrading the
mailman version could be considered.  Unfortunately, I don't know who that
is -- I was hoping that someone on this list would mention the appropriate
contact as a side effect of this thread, so I didn't have to explicitly go
looking.

-Ben


From nobody Thu Sep 25 06:38:14 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18BB1A6FD9 for ; Thu, 25 Sep 2014 06:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level: 
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
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 dZEfsuIfOBIB for ; Thu, 25 Sep 2014 06:38:12 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 318171A0023 for ; Thu, 25 Sep 2014 06:38:12 -0700 (PDT)
Received: from unnumerable.local (pool-173-57-97-85.dllstx.fios.verizon.net [173.57.97.85]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8PDcB75067430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Thu, 25 Sep 2014 08:38:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-97-85.dllstx.fios.verizon.net [173.57.97.85] claimed to be unnumerable.local
Message-ID: <54241AC3.4000104@nostrum.com>
Date: Thu, 25 Sep 2014 08:38:11 -0500
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: wgchairs@ietf.org
Subject: Re: HEADS UP: Default notification list change
References: <5422E514.8070700@qti.qualcomm.com> <542308F1.8020709@qti.qualcomm.com> <54230BF8.1050204@alum.mit.edu> <54231063.1010704@nostrum.com> <5423293A.4080802@alum.mit.edu>
In-Reply-To: <5423293A.4080802@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/uo420qiRaP166ARk6XDCjQdMWDc
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Sep 2014 13:38:14 -0000

On 9/24/14 3:27 PM, Paul Kyzivat wrote:
> On 9/24/14 2:41 PM, Robert Sparks wrote:
>>
>> On 9/24/14 1:22 PM, Paul Kyzivat wrote:
>>> Pete,
>>>
>>> Below is clear as far as it goes, but it leaves me with two questions:
>>>
>>> - You say "the default notification list", which implies to me that
>>> this can be overridden. How? Can I see and edit this definition
>>> somewhere?
>> You can see it on the Document's main page.
>>
>> Look at  for
>> example at the line that says:
>> Send notices to: stir-chairs@tools.ietf.org,
>> draft-ietf-stir-threats@tools.ietf.org
>>
>> At , 
>> you'll see
>> Send notices to:     No addresses provided
>
> I never knew that - never noticed.
>
>> Addresses will get added to that automatically when you pubreq the doc.
>> With the upcoming change, when you make a doc a WG item, the group's
>> list will automatically get added.
>>
>> Addresses can be manually added or removed at any time. Right now, only
>> the secretariat and ADs can edit the field though. It would be
>> reasonable, IMHO, to let wg chairs do that too (you'd see a pencil,
>> similar to what you see now for the shepherd or the intended status.)
>
> So for now chairs have no control over this. So I guess it doesn't 
> matter much to us. :-)
Well, as part of the chair/shepherd activities, checking occasionally 
that its set to the best values it can be given the context of a given 
draft would be good. Until its changed so that you can edit it directly, 
you can always ask the secretariat or an AD to make the change for you.
>
>     Thanks,
>     Paul
>
>>> - how is this notification list referenced for sending stuff? Is there
>>> some foo such that .foo@tools.ietf.org references this
>>> notification list?
>> This field gets used internally in the tracker to add addresses to the
>> messages it sends when document events happen (such states change,
>> ballots are entered, etc.)
>>
>> There is no @tools.ietf.org alias that refers directly to it.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>> On 9/24/14 2:09 PM, Pete Resnick wrote:
>>>> OK, I seem to have confused some folks, so let me try one last time to
>>>> unmuddle. My apologies for my broken brain:
>>>>
>>>> @tools.ietf.org is the authors.
>>>> .all@tools.ietf.org is the authors and the chairs (and the 
>>>> AD,
>>>> once it starts IESG processing).
>>>>
>>>> The default notification list for WG documents is currently
>>>> "-chairs@tools.ietf.org, @tools.ietf.org".
>>>>
>>>> The default notification list for WG documents is changing to
>>>> ".all@tools.ietf.org, @ietf.org".
>>>>
>>>> Also, when a shepherd is assigned, the shepherd's email address is 
>>>> added
>>>> to the list.
>>>>
>>>> I hope that makes more sense.
>>>>
>>>> pr
>>>>
>>>
>>
>


From nobody Thu Sep 25 12:59:33 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D811A033B for ; Thu, 25 Sep 2014 12:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 VLOW2TNQE_R2 for ; Thu, 25 Sep 2014 12:59:30 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174561A0337 for ; Thu, 25 Sep 2014 12:59:29 -0700 (PDT)
X-AuditID: 12074424-f79346d000004923-56-54247420d270
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id AC.A9.18723.02474245; Thu, 25 Sep 2014 15:59:28 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s8PJxPKr006524 for ; Thu, 25 Sep 2014 15:59:28 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8PJxNT5001243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 25 Sep 2014 15:59:24 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8PJxNCP028622; Thu, 25 Sep 2014 15:59:23 -0400 (EDT)
Date: Thu, 25 Sep 2014 15:59:23 -0400 (EDT)
From: Benjamin Kaduk 
To: WG Chairs 
Subject: Re: [BOFChairs] best practices for dealing with DMARC fallout on IETF lists
In-Reply-To: 
Message-ID: 
References:  <54224924.6080808@cisco.com>  <54224DB1.9030607@cisco.com> <11835.1411566784@sandelman.ca>   <54237403.5040602@gmail.com> 
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nrqtQohJiMOunscX//VMYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWLbSeaCDywVx2cuZmlgfMPcxcjJISFgIvFp8i4WCFtM4sK9 9WxdjFwcQgKzmSQWT//NDuGcZJRofboXKnOLSeLH45fMEE4Do8S5KwuB+jk4WAS0JV7vzAQZ xSagIjHzzUY2EFtEQFHi/ZtuMFtYIEyiZ/ZKsNWcAk4SH7ZMBFvNK+AosWf1DkaImX+YJHq/ P2QFSYgK6Eis3j8FqkhQ4uTMJ2A2s4CWxPLp21gmMArMQpKahSS1gJFpFaNsSm6Vbm5iZk5x arJucXJiXl5qka65Xm5miV5qSukmRnAAuqjsYGw+pHSIUYCDUYmH94OPcogQa2JZcWXuIUZJ DiYlUd6uUJUQIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8HPpAOd6UxMqq1KJ8mJQ0B4uSOO+m H3whQgLpiSWp2ampBalFMFkZDg4lCV7BIqBGwaLU9NSKtMycEoQ0EwcnyHAeoOE7QWp4iwsS c4sz0yHypxiNOVqa3vYycazr/NbPJMSSl5+XKiXOexOkVACkNKM0D24aLIm8YhQHek6YdwdI FQ8wAcHNewW0igloldIRZZBVJYkIKakGxtQj9g5dT2OLRJpT/iZPKm/zLpQ/qDPv9bVba54a CnJGmC1+ccz4wa8f6/jkM3nLeE7O+Cbq+/qGVzD3hy9KfspGhQZHLVfVXfDVdiu2PV2xcYf1 1gXOdhcv/Nm/3egnq2WDsch1s5SCjfO3rZSf6jgpIaGDTWSisGvIycn7GUu8c+YIWLF6KLEU ZyQaajEXFScCANHrJ9j9AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/RcXJFFFjHSRqqe61gWptJ02zBxU
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Sep 2014 19:59:32 -0000

On Wed, 24 Sep 2014, Benjamin Kaduk wrote:

> I really think that this is a question for the people who maintain the
> mailman deployment for the IETF.  Among other things, upgrading the
> mailman version could be considered.  Unfortunately, I don't know who that
> is -- I was hoping that someone on this list would mention the appropriate
> contact as a side effect of this thread, so I didn't have to explicitly go
> looking.

It seems like this is just ietf-action, so I made [www.ietf.org/rt
#69178].


Basically, the status seems to be "they're looking into options", so we
should wait and see.

-Ben


From nobody Fri Sep 26 04:23:24 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1872C1A1AA7 for ; Fri, 26 Sep 2014 04:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level: 
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 DaiPPzzyW9_y for ; Fri, 26 Sep 2014 04:23:21 -0700 (PDT)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A3C1A1AC8 for ; Fri, 26 Sep 2014 04:23:21 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id D962728B003D; Fri, 26 Sep 2014 07:23:20 -0400 (EDT)
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 956A01F8032; Fri, 26 Sep 2014 07:23:20 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_842E4BE5-CF83-45B2-9B02-2654D63ED6CB"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: HEADS UP: Default notification list change
From: Sandra Murphy 
In-Reply-To: <54241AC3.4000104@nostrum.com>
Date: Fri, 26 Sep 2014 07:23:19 -0400
Message-Id: <74D1E10E-8622-4971-A59F-0C5F570BA82F@tislabs.com>
References: <5422E514.8070700@qti.qualcomm.com> <542308F1.8020709@qti.qualcomm.com> <54230BF8.1050204@alum.mit.edu> <54231063.1010704@nostrum.com> <5423293A.4080802@alum.mit.edu> <54241AC3.4000104@nostrum.com>
To: Robert Sparks 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/fxueXwnFxgH7VVYWNjoSk83326k
Cc: wgchairs@ietf.org, Sandra Murphy 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 11:23:23 -0000

--Apple-Mail=_842E4BE5-CF83-45B2-9B02-2654D63ED6CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Sep 25, 2014, at 9:38 AM, Robert Sparks  wrote:

>>> This field gets used internally in the tracker to add addresses to =
the
>>> messages it sends when document events happen (such states change,
>>> ballots are entered, etc.)

This pretty much answers my question - just what is a notification?

Right now, the wg list gets a message every time a wg doc gets submitted =
("I-D Action:" etc).  And I know the authors get a message every time =
the chair changes the state on a document.  (That must be a pain when =
the chairs do house-cleaning).

So this field is not to change the already existing notifications, but =
to add additional recipients to what the system does?  Right?  There's =
no default to that field that is making those notifications happen, they =
are built in to the system?  (I.e., chairs don't have to monitor to make =
sure that the field's default is not overwritten and that no redesign of =
the system changes the system's default)

--Sandy


--Apple-Mail=_842E4BE5-CF83-45B2-9B02-2654D63ED6CB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUJUyoAAoJEHplpQeet0IZc0MP/3EH/jlPoVih9mLFf9OMTkLq
rRnNWFjxoVbLciJDtDkqEFQMnReui5rP3nAVtMuU/q/o69TJozoeosEO4ddPEugh
hcoUKe1wVurwDiSyydXoK4oHzua1gSRzXg6JtUR30P93Ix79SSJkc0DDyV4uCoBg
s3C88X5ewv5YD+9/wrm5cOGG0zrf7GEEaZhqmfQkvTQ6/PWcCLoAoo4zWTDDr+gQ
5LE05gemNynOOsqnuG8R3s83ddJevjMwsJczuRfeTjwN1TGNkcVp32GZMU+tzRNZ
8MJde4QfafXBHUkOvlg7JCoTboBH1ax2Ajj22nl5++hJifFP1wkA4C+WwI4g06tj
g89IfEQJIG0FRomxVJdOZtcxjUhklSPwc3ISoA1R/Q+m/n8IUDRf8/BkhL+Px4zn
uMQddj4/ecgvLY8J9ntd0pTiZSOuGpkgLYbHo2be/HPNvSk9SFvOw8Zo2fC0nJbG
5A0PPd5C6z84NQUe8zY0O5eVfDq0rmzNdRv4WIwYHBo3pTzXmlfUbIa7QpFS5vtc
67Wg7axkBHzUArbAODxaBtcbRi2GJKcuMWnZwYC+7zv8dUn7WjdyfJA/ja7rJPPr
mCYDO1YoGC9Q0kx3MZWFpScewgqXbd9z4kaGSfvg7oS2lI+/fwignv02exihbHLm
h1Tu7xg1gJiQPn+qAbk8
=EtUb
-----END PGP SIGNATURE-----

--Apple-Mail=_842E4BE5-CF83-45B2-9B02-2654D63ED6CB--


From nobody Fri Sep 26 06:12:34 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441E21A6F92 for ; Fri, 26 Sep 2014 06:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level: 
X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.786] autolearn=ham
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 ifOKqTyFlQiD for ; Fri, 26 Sep 2014 06:12:28 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 02D1F1A6EE6 for ; Fri, 26 Sep 2014 06:12:27 -0700 (PDT)
Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8QDCH3P089504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Fri, 26 Sep 2014 08:12:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local
Message-ID: <5425662D.8020507@nostrum.com>
Date: Fri, 26 Sep 2014 08:12:13 -0500
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Sandra Murphy 
Subject: Re: HEADS UP: Default notification list change
References: <5422E514.8070700@qti.qualcomm.com> <542308F1.8020709@qti.qualcomm.com> <54230BF8.1050204@alum.mit.edu> <54231063.1010704@nostrum.com> <5423293A.4080802@alum.mit.edu> <54241AC3.4000104@nostrum.com> <74D1E10E-8622-4971-A59F-0C5F570BA82F@tislabs.com>
In-Reply-To: <74D1E10E-8622-4971-A59F-0C5F570BA82F@tislabs.com>
Content-Type: multipart/alternative; boundary="------------050904010305090204070108"
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/K7h4yrj8uO4WKH8A-WZ-MzuH-WA
Cc: wgchairs@ietf.org
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 13:12:30 -0000

This is a multi-part message in MIME format.
--------------050904010305090204070108
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit


On 9/26/14 6:23 AM, Sandra Murphy wrote:
> On Sep 25, 2014, at 9:38 AM, Robert Sparks  wrote:
>
>>>> This field gets used internally in the tracker to add addresses to the
>>>> messages it sends when document events happen (such states change,
>>>> ballots are entered, etc.)
> This pretty much answers my question - just what is a notification?
>
> Right now, the wg list gets a message every time a wg doc gets submitted ("I-D Action:" etc).  And I know the authors get a message every time the chair changes the state on a document.  (That must be a pain when the chairs do house-cleaning).
>
> So this field is not to change the already existing notifications, but to add additional recipients to what the system does?  Right?
So, first, this is not a new field, and has been part of where many 
messages are sent for a long time.

The start of this thread was a heads up that the values that 
automatically get put into the field at various points in the document 
lifecycle is changing
to reach more people than what the current set does.

For some things the tracker sends mail about, there are some hard-coded 
(or calculated) recipients.
The 'I-D Action' messages you call out, for example, have purely 
calculated recipients - the notify field is not currently used there.
(The message is sent from 
. 
The to calculation looks like:
  m.to = settings.IDSUBMIT_ANNOUNCE_LIST_EMAIL
  if submission.group and submission.group.list_email:
      m.cc = submission.group.list_email
)

For other things, like the messages that talk about state changes to a 
document (those with a Subject that starts as
"ID Tracker State Update Notice:") the Notify field is the only source 
of recipients.
The relevant code for that is at


If you're curious, you can look through those two files to see how the 
recipients are determined for most of the other messages the tracker 
will send.

> There's no default to that field that is making those notifications happen, they are built in to the system?  (I.e., chairs don't have to monitor to make sure that the field's default is not overwritten and that no redesign of the system changes the system's default)
I hope the above answers your question.
As I said first, the notify field has been used for recipient 
calculation for many messages for a long time now.
Looking at it occasionally to make sure it's the best set for the 
current context of the document is a good idea.
You shouldn't have to monitor it closely against surprising changes.
>
> --Sandy
>


--------------050904010305090204070108
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    On 9/26/14 6:23 AM, Sandra Murphy
      wrote:

    
    
      On Sep 25, 2014, at 9:38 AM, Robert Sparks <rjsparks@nostrum.com> wrote:


      
        
          
            This field gets used internally in the tracker to add addresses to the
messages it sends when document events happen (such states change,
ballots are entered, etc.)

          
        
      
      This pretty much answers my question - just what is a notification?

Right now, the wg list gets a message every time a wg doc gets submitted ("I-D Action:" etc).  And I know the authors get a message every time the chair changes the state on a document.  (That must be a pain when the chairs do house-cleaning).

So this field is not to change the already existing notifications, but to add additional recipients to what the system does?  Right?  
    
    So, first, this is not a new field, and has been part of where many
    messages are sent for a long time.

    

    The start of this thread was a heads up that the values that
    automatically get put into the field at various points in the
    document lifecycle is changing

    to reach more people than what the current set does.

    

    For some things the tracker sends mail about, there are some
    hard-coded (or calculated) recipients.

    The 'I-D Action' messages you call out, for example, have purely
    calculated recipients - the notify field is not currently used
    there.

    (The message is sent from
    <http://wiki.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/submit/mail.py#L86>.
    The to calculation looks like:

    �m.to = settings.IDSUBMIT_ANNOUNCE_LIST_EMAIL

    �if submission.group and submission.group.list_email:

    �� � m.cc = submission.group.list_email

    )

    

    For other things, like the messages that talk about state changes to
    a document (those with a Subject that starts as

    
    "ID Tracker State Update Notice:") the Notify
    field is the only source of recipients.

    The relevant code for that is at

    <http://wiki.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/doc/mails.py#L17>

    

    If you're curious, you can look through those two files to see how
    the recipients are determined for most of the other messages the
    tracker will send.

    

    
      There's no default to that field that is making those notifications happen, they are built in to the system?  (I.e., chairs don't have to monitor to make sure that the field's default is not overwritten and that no redesign of the system changes the system's default)
    
    I hope the above answers your question.

    As I said first, the notify field has been used for recipient
    calculation for many messages for a long time now.

    Looking at it occasionally to make sure it's the best set for the
    current context of the document is a good idea.

    You shouldn't have to monitor it closely against surprising changes.
    

    
      
--Sandy


    
    

  


--------------050904010305090204070108--


From nobody Fri Sep 26 08:16:24 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65D81A8981; Fri, 26 Sep 2014 08:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 wWubEe7ZA1X3; Fri, 26 Sep 2014 08:15:55 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AB61A898D; Fri, 26 Sep 2014 08:15:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: IETF Agenda 
To: Working Group Chairs 
Subject: Cutoff Today - 91st IETF - Working Group/BOF/IRTF Scheduling
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140926151555.26734.609.idtracker@ietfa.amsl.com>
Date: Fri, 26 Sep 2014 08:15:55 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/UbTtCYYSCbOksjytL2-8pkyFvWA
Cc: irsg@irtf.org
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: IETF Agenda 
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 15:15:58 -0000

-----------------------------------------------------------------
91st IETF – Honolulu, HI, USA
Meeting Dates: November 9 - 14, 2014
-----------------------------------------------------------------

The cutoff for WG/BOF/IRTF session requests is today at UTC 23:59.

NOTE: Please ensure your list of conflicts is complete and up to date prior to submitting your session request.

The milestones and deadlines for scheduling-related activities are as follows:
Cut-off dates are subject to change.

•	2014-09-26 (Friday): Cut-off date for requests to schedule Working Group meetings at UTC 23:59. To request a Working Group session, use the IETF Meeting Session Request Tool.
•	2014-09-26 (Friday): Cut-off date for BOF proposal requests to Area Directors at UTC 23:59. To request a BOF, please see instructions on Requesting a BOF.
•	2014-10-03 (Friday): Cut-off date for Area Directors to approve BOFs at UTC 23:59.
•	2014-10-10 (Friday): Preliminary agenda published for comment.
•	2014-10-13 (Monday): Cut-off date for requests to reschedule Working Group and BOF meetings UTC 23:59.
•	2014-10-17 (Friday): Final agenda to be published.
•	2014-10-27 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.
•	2014-11-03 (Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.
•	2014-12-05 (Friday): Proceedings submission cutoff date by UTC 23:59, upload using IETF Meeting Materials Management Tool.
•	2014-12-26 (Friday): Proceedings submission corrections cutoff date by UTC 23:59, upload using IETF Meeting Materials Management Tool.


===============================================================
For your convenience, comprehensive information on requesting meeting sessions is presented below:

1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions.  The URL for the tool is:

https://datatracker.ietf.org/secr/sreq/

Instructions for using the tool are available at:

http://www.ietf.org/wg/request-tool-instructions.html

If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org.  If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s).

Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s).

When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line.

2. BOFs will NOT be scheduled unless the Area Director approves the BOF. The proponents behind a BOF need to contact a relevant Area Director, preferably well in advance of the BOF approval deadline date. The AD needs to have the full name of the BOF, its acronym, suggested names of chairs, an agenda, full description of the BOF and the information covered in item 4. Please read RFC 5434 for instructions on how to drive a successful BOF effort. The approval depends on, for instance, Internet-Drafts and list discussion on the suggested topic. BOF agenda requests, if approved, will be submitted to the IETF Secretariat by the ADs.

3. A Working Group may request either one or two sessions.  If your Working Group requires more than two sessions, then your request must be approved by an Area Director.  Additional sessions will be assigned, based on availability, after Monday, October 13th, 2014, the cut-off date for requests to reschedule a session.

4. You MUST provide the following information before a Working Group or BOF session will be scheduled:

a. Working Group or BOF full name with acronym in brackets: 
b. AREA under which Working Group or BOF appears:
c. CONFLICTS you wish to avoid, please be as specific as possible:
d. Expected Attendance:
e. Special requests:
f. Number of sessions:
g. Length of session: 1 hour, 1.5 hours, 2 hours, 2.5 hours
       		
For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt).

===============================================================

Submitting Session Agendas

For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible.  Draft Working Group agendas are due Monday, October 27th, 2014 at UTC 23:59.  Revised Working Group agendas are due no later than Monday, November 3rd, 2014 at UTC 23:59.  The proposed agenda for a BOF session should be submitted along with your request for a session.  Please be sure to copy your Area Director on that message.

Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting.  If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved.

The URL for the tool is:

https://datatracker.ietf.org/secr/proceedings/

Additional information about this tool is available at:

http://www.ietf.org/wg/meeting-materials.html

Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" webpage as soon as they are submitted.

The URL for the "IETF 91 Meeting Materials" Web page is:

https://datatracker.ietf.org/meeting/91/materials.html

If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool."  The same User ID and password will work for both tools.  If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved.  If you require assistance in using either tool, or wish to report a bug, then please send a message to:
ietf-action@ietf.org.

===============================================================
For your convenience please find a list of the IETF Area Directors with their e-mail addresses below:

IETF Chair 
Jari Arkko 

Applications Area (app)
Barry Leiba 
Pete Resnick 

Internet Area (int) 
Brian Haberman  
Ted Lemon 

Operations & Management Area (ops) 
Benoit Claise  
Joel Jaeggli 

Real-time Applications and Infrastructure Area (rai)
Richard Barnes   
Alissa Cooper   

Routing Area (rtg) 
Alia Atlas 
Adrian Farrel   

Security Area (sec) 
Stephen Farrell 
Kathleen Moriarty   

Transport Area (tsv) 
Spencer Dawkins  
Martin Stiemerling  

 ===========================================================
90th IETF Meeting Attendance Numbers

6lo - 66
6tisch - 63
abfab – 42
ace - 70
actn (BoF) - 114
alto  - 38
appsawg/apparea - 157
aqm - 50
avtcore - 49
avtext - 40
bfd - 46
bmwg - 24
ccamp - 42
ccamp (2nd session) - 44
cdni – 35
cfrg - 80
clue – 23
clue (2nd session) - 21
core - 64
core (2nd session) – 31
dane - 158
dart - 57
dclcrg (RG BoF) - 37
dhc - 44
dice - 58
dime - 17
dispatch - 69
dmm - 30
dmm (2nd session) - 28
dnsop - 149
dnssd - 63
dtnwg (BoF) - 85
ecrit - 28
forces - 76
grow - 45
homenet - 136
httpauth - 56
httpbis - Not Provided
httpbis (2nd session) - Not Provided
i2rs - 119
ianaplan - 170
icnrg (RG) - 90
idr - 72
intarea (AG) - 94
ippm - 44
ipsecme - 37
IRTF Open Meeting - 87
isis - 42
jose - 41
kitten - 16
l2vpn - 96
l3vpn - 50
lisp - 24
lmap - 36
lwig - 23
manet - 17
mboned - 16
mif – 49
mile - 32
mmusic - 56
mmusic (2nd session) - 42
mpls - 123
mpls (2nd session) - 68
mptcp - 73
netconf - 94
netext - 26
netmod - 106
nfsv4 - 17
nmrg (RG) - 56
ntp (combined with tictoc) - 30
nvo3 - 102
oauth - 44
opsawg/opsarea - 79
ospf - 42
paws – 23
pce - 87
pim - 21
ppsp - 14
precis - 27
pwe3 - 31
radext - 11
rfcform - 66
rmcat - 52
rmcat (2nd session) - 31
roll - 33
rtcweb - 101
rtcweb (2nd session) - 87
rtgarea (AG) - 150
rtgwg - 64
saag (AG) - 168
sacm - 40
sacm (2nd session) - 29
scim - 28
sdnrg (RG) – 193
sfc - 248
sidr - 60
sipcore - 34
siprec - 11
softwire - 54
spring - 157
stir - 43
straw - 23
sunset4 - 75
taps - 107
tcpinc - 96
tcpm - 46
tictoc (combined with ntp) - 30
tls - 139
tls (2nd session) - 94
tram - 30
trans - 44
trill - 19
tsvwg - 75
tsvwg (2nd session) - 76
ucan (BoF) - 159
uta - 102
urnbis - 29
v6ops - 198
v6ops (2nd session) – 62
vnfpool (BoF) - 180
weirds - 60


From nobody Fri Sep 26 08:21:01 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9624A1A899B for ; Fri, 26 Sep 2014 08:20:52 -0700 (PDT)
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, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=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 SxEKsbuTueqh for ; Fri, 26 Sep 2014 08:20:48 -0700 (PDT)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74861A896C for ; Fri, 26 Sep 2014 08:20:48 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id v10so694514qac.15 for ; Fri, 26 Sep 2014 08:20:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EIbFcx3fGj9g/wqPnfNW0pbxHIyz8Sc0yzSjBih2MRU=; b=pv22DE61rIBiwdimd3CKIbA0vtCXJL7C2SMZJMsZRyBQsnnG8XQZNZPefNLI+WI9Gf YrCy2xtFhTnUDe4cHjx8vBllaxX5ly1C5cYMRRPDZqDEqaAaaVZDJFYwyL2+mSGdctQO P/PE9fooPl6hjDU/GD/+wfoL3FsFifK9kcYfxInlRSUiTtk8Md4SjcyoY+rUQSwp0Q09 s+1WMfPdFteafb1ImE/+DRSuX7FtXhErmxYcD/Yru7ZjtAsv2uMwSFdwha95+yqsh+2a AUhYBvId9EXJG3bL4ttpJIKddFLmHgtKiWA0XLUSo/4nu8Uh+De5heZqh/Ek56C/HHBY /G2g==
X-Received: by 10.140.86.145 with SMTP id p17mr33296944qgd.57.1411744847790; Fri, 26 Sep 2014 08:20:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.42.65 with HTTP; Fri, 26 Sep 2014 08:20:27 -0700 (PDT)
In-Reply-To: <5425662D.8020507@nostrum.com>
References: <5422E514.8070700@qti.qualcomm.com> <542308F1.8020709@qti.qualcomm.com> <54230BF8.1050204@alum.mit.edu> <54231063.1010704@nostrum.com> <5423293A.4080802@alum.mit.edu> <54241AC3.4000104@nostrum.com> <74D1E10E-8622-4971-A59F-0C5F570BA82F@tislabs.com> <5425662D.8020507@nostrum.com>
From: "Andrew G. Malis" 
Date: Fri, 26 Sep 2014 11:20:27 -0400
Message-ID: 
Subject: Re: HEADS UP: Default notification list change
To: Robert Sparks 
Content-Type: multipart/alternative; boundary=001a11c124982a8a920503f9760d
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/aytDuv3ZGtIlcfwzdgYsfeTLQcs
Cc: Working Group Chairs , Sandra Murphy 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 15:20:52 -0000

--001a11c124982a8a920503f9760d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

There's a subtext in this announcement that's implied but not directly
stated, which is (I assume) that the IESG wants this change because they
want the WG participants to be aware of state changes in WG documents.

Assuming this is correct, when would it be appropriate (if ever) to remove
the WG from the notification list for a WG draft?

Cheers,
Andy


On Fri, Sep 26, 2014 at 9:12 AM, Robert Sparks  wrote=
:

>
> On 9/26/14 6:23 AM, Sandra Murphy wrote:
>
> On Sep 25, 2014, at 9:38 AM, Robert Sparks   wrote:
>
>
>   This field gets used internally in the tracker to add addresses to the
> messages it sends when document events happen (such states change,
> ballots are entered, etc.)
>
>   This pretty much answers my question - just what is a notification?
>
> Right now, the wg list gets a message every time a wg doc gets submitted =
("I-D Action:" etc).  And I know the authors get a message every time the c=
hair changes the state on a document.  (That must be a pain when the chairs=
 do house-cleaning).
>
> So this field is not to change the already existing notifications, but to=
 add additional recipients to what the system does?  Right?
>
>  So, first, this is not a new field, and has been part of where many
> messages are sent for a long time.
>
> The start of this thread was a heads up that the values that automaticall=
y
> get put into the field at various points in the document lifecycle is
> changing
> to reach more people than what the current set does.
>
> For some things the tracker sends mail about, there are some hard-coded
> (or calculated) recipients.
> The 'I-D Action' messages you call out, for example, have purely
> calculated recipients - the notify field is not currently used there.
> (The message is sent from
> 
> .
> The to calculation looks like:
>  m.to =3D settings.IDSUBMIT_ANNOUNCE_LIST_EMAIL
>  if submission.group and submission.group.list_email:
>      m.cc =3D submission.group.list_email
> )
>
> For other things, like the messages that talk about state changes to a
> document (those with a Subject that starts as
> "ID Tracker State Update Notice:") the Notify field is the only source of
> recipients.
> The relevant code for that is at
>
> 
> 
>
> If you're curious, you can look through those two files to see how the
> recipients are determined for most of the other messages the tracker will
> send.
>
>  There's no default to that field that is making those notifications happ=
en, they are built in to the system?  (I.e., chairs don't have to monitor t=
o make sure that the field's default is not overwritten and that no redesig=
n of the system changes the system's default)
>
>  I hope the above answers your question.
> As I said first, the notify field has been used for recipient calculation
> for many messages for a long time now.
> Looking at it occasionally to make sure it's the best set for the current
> context of the document is a good idea.
> You shouldn't have to monitor it closely against surprising changes.
>
>
> --Sandy
>
>
>
>

--001a11c124982a8a920503f9760d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

There's a subtext in this announcement that's impl=
ied but not directly stated, which is (I assume) that the IESG wants this c=
hange because they want the WG participants to be aware of state changes in=
 WG documents.
Assuming this is correct, when would it b=
e appropriate (if ever) to remove the WG from the notification list for a W=
G draft?

Cheers,
Andy


On Fri, S=
ep 26, 2014 at 9:12 AM, Robert Sparks <rjsparks@nostrum.com> wrote:

 =20
   =20
 =20
  
    

    On 9/26/14 6:23 AM, Sandra Murphy
      wrote:

    
    
      On Sep 25, 2014, at 9:38 AM, Robert Sparks <rjsparks@nostrum.com> wrote=
:


      
        
          
            This field gets used internally in the tracker to add addr=
esses to the
messages it sends when document events happen (such states change,
ballots are entered, etc.)

          
        
      
      This pretty much answers my question - just what is a notificati=
on?

Right now, the wg list gets a message every time a wg doc gets submitted (&=
quot;I-D Action:" etc).  And I know the authors get a message every ti=
me the chair changes the state on a document.  (That must be a pain when th=
e chairs do house-cleaning).

So this field is not to change the already existing notifications, but to a=
dd additional recipients to what the system does?  Right?  
    
    So, first, this is not a new field, and has been part of where many
    messages are sent for a long time.

    

    The start of this thread was a heads up that the values that
    automatically get put into the field at various points in the
    document lifecycle is changing

    to reach more people than what the current set does.

    

    For some things the tracker sends mail about, there are some
    hard-coded (or calculated) recipients.

    The 'I-D Action' messages you call out, for example, have purel=
y
    calculated recipients - the notify field is not currently used
    there.

    (The message is sent from
    <http://wiki.tools.ietf.org/tools/i=
etfdb/browser/trunk/ietf/submit/mail.py#L86>.
    The to calculation looks like:

    =C2=A0m.to =3D settings.I=
DSUBMIT_ANNOUNCE_LIST_EMAIL

    =C2=A0if submission.group and submission.group.list_email:

    =C2=A0=C2=A0 =C2=A0 m.cc =3D submission.group.list_email

    )

    

    For other things, like the messages that talk about state changes to
    a document (those with a Subject that starts as

   =20
    "ID Tracker State Update Notice:") the Notify
    field is the only source of recipients.

    The relevant code for that is at

    <http://wiki.tools.ietf.org/tools/iet=
fdb/browser/trunk/ietf/doc/mails.py#L17>

    

    If you're curious, you can look through those two files to see how
    the recipients are determined for most of the other messages the
    tracker will send.

    

    
      There's no default to that field that is making those notifi=
cations happen, they are built in to the system?  (I.e., chairs don't h=
ave to monitor to make sure that the field's default is not overwritten=
 and that no redesign of the system changes the system's default)
    
    I hope the above answers your question.

    As I said first, the notify field has been used for recipient
    calculation for many messages for a long time now.

    Looking at it occasionally to make sure it's the best set for the
    current context of the document is a good idea.

    You shouldn't have to monitor it closely against surprising changes=
.
    

    
      --Sandy


    
    

  




--001a11c124982a8a920503f9760d--


From nobody Fri Sep 26 08:54:02 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF4A1A89FE for ; Fri, 26 Sep 2014 08:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.787
X-Spam-Level: 
X-Spam-Status: No, score=-7.787 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 oQaSytIkd4qL for ; Fri, 26 Sep 2014 08:53:58 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8631A89FC for ; Fri, 26 Sep 2014 08:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411746838; x=1443282838; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=C8lSobQKNcZiVlDMaK32PWKGMfjCuHJoEMYoyEp2XJ4=; b=yfGtG76/BBioVjPRQr2400HAd3GB86R4zCjmYx4DUSyMFTlV2JAUePFa ZiYMFZHI58+AsynENGBSqrglM2V1OifDXmSNriNffxyheaU5c5TTGAnRH zAnCmfLdIxTGuasSMA55aThBcsfzfDYELI0oL49OWn5B3xu91sWkgyslx 4=;
X-IronPort-AV: E=McAfee;i="5600,1067,7572"; a="74928684"
Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 26 Sep 2014 08:53:58 -0700
X-IronPort-AV: E=Sophos;i="5.04,604,1406617200"; d="scan'208";a="30666728"
Received: from nasanexhc16.na.qualcomm.com ([10.45.158.213]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Sep 2014 08:53:57 -0700
Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc16.na.qualcomm.com (10.45.158.213) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 26 Sep 2014 08:53:57 -0700
Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 26 Sep 2014 08:53:47 -0700
Message-ID: <54258C09.7020202@qti.qualcomm.com>
Date: Fri, 26 Sep 2014 10:53:45 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: "Andrew G. Malis" 
Subject: Re: HEADS UP: Default notification list change
References: <5422E514.8070700@qti.qualcomm.com> <542308F1.8020709@qti.qualcomm.com> <54230BF8.1050204@alum.mit.edu> <54231063.1010704@nostrum.com> <5423293A.4080802@alum.mit.edu> <54241AC3.4000104@nostrum.com> <74D1E10E-8622-4971-A59F-0C5F570BA82F@tislabs.com> <5425662D.8020507@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/-nDuKGZP8Xyezp59YFtNx2F6tmY
Cc: Working Group Chairs , Sandra Murphy , Robert Sparks 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 15:54:00 -0000

On 9/26/14 10:20 AM, Andrew G. Malis wrote:
> There's a subtext in this announcement that's implied but not directly 
> stated, which is (I assume) that the IESG wants this change because 
> they want the WG participants to be aware of state changes in WG 
> documents.

The subtext (if there is any) is that the IESG (or at least some members 
thereof) want this change because they want the WG participants to be 
aware of the IESG Evaluation discussions (DISCUSSes and COMMENTs). The 
notification list gets used for who gets Cc'ed on that as well.

> when would it be appropriate (if ever) to remove the WG from the 
> notification list for a WG draft?

When holding that discussion would be "unproductive". :-)

pr

-- 
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478


From nobody Fri Sep 26 09:44:19 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F55B1A8A7D for ; Fri, 26 Sep 2014 09:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 ZzE-6fqLafcK for ; Fri, 26 Sep 2014 09:44:17 -0700 (PDT)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6A41A8A6E for ; Fri, 26 Sep 2014 09:44:17 -0700 (PDT)
Received: by mail-qg0-f42.google.com with SMTP id z60so8075954qgd.1 for ; Fri, 26 Sep 2014 09:44:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=skQGodQXqe71VL5lhBcPzOT/mEkyg5sk4YKiutDgdzA=; b=zMtc+cnk+30xiNSJqgz0Y2EgqOMgmgPbTmkDQtgt6/qAjqpwg9I9CuaK4sbA8z+SXe d2PRFjiPiTHtfOBiSUmyWVlHs4l9FDhzWrCcvhIba+OE+NsBBDU2wOMZoHKulHyh6HYM SkausdZQhLCuFUxZp6TdwpCnBIeOwzYPs8MPNd5lxnnbAG6hCRy0ALOnyVexMmqP8Kv5 Zg3T3PVGQFl+Ft2w0Qi8+0c1daq3dF8HwKbEB4gq4dtAQmPY77DtdaFLvMP4APmKk/KE 7SWe1U5PbkFQiy8JfC2YxxtAOTCqONpfl3AmMcMvu5VOn92lzoAHyumVeE1WzjGzmUGz gSrQ==
X-Received: by 10.229.65.135 with SMTP id j7mr29292586qci.22.1411749856460; Fri, 26 Sep 2014 09:44:16 -0700 (PDT)
Received: from ?IPv6:2601:6:3a80:77e:31ac:56b5:56d8:a971? ([2601:6:3a80:77e:31ac:56b5:56d8:a971]) by mx.google.com with ESMTPSA id p45sm4101369qgd.49.2014.09.26.09.44.14 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Sep 2014 09:44:15 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: HEADS UP: Default notification list change
From: Suzanne Woolf 
In-Reply-To: <54258C09.7020202@qti.qualcomm.com>
Date: Fri, 26 Sep 2014 12:44:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <32FAD265-90B2-448F-975F-4B8A5AE1B825@gmail.com>
References: <5422E514.8070700@qti.qualcomm.com> <542308F1.8020709@qti.qualcomm.com> <54230BF8.1050204@alum.mit.edu> <54231063.1010704@nostrum.com> <5423293A.4080802@alum.mit.edu> <54241AC3.4000104@nostrum.com> <74D1E10E-8622-4971-A59F-0C5F570BA82F@tislabs.com> <5425662D.8020507@nostrum.com>  <54258C09.7020202@qti.qualcomm.com>
To: Pete Resnick 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/oMCMWfYNMyjV5bAO9m0coAmWLSw
Cc: Working Group Chairs , Robert Sparks , Sandra Murphy 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 16:44:18 -0000

On Sep 26, 2014, at 11:53 AM, Pete Resnick  =
wrote:

> On 9/26/14 10:20 AM, Andrew G. Malis wrote:
>> There's a subtext in this announcement that's implied but not =
directly stated, which is (I assume) that the IESG wants this change =
because they want the WG participants to be aware of state changes in WG =
documents.
>=20
> The subtext (if there is any) is that the IESG (or at least some =
members thereof) want this change because they want the WG participants =
to be aware of the IESG Evaluation discussions (DISCUSSes and COMMENTs). =
The notification list gets used for who gets Cc'ed on that as well.

I like that reason.

>> when would it be appropriate (if ever) to remove the WG from the =
notification list for a WG draft?
>=20
> When holding that discussion would be "unproductive". :-)

:) I can imagine curmudgeons among us who might object to the "clutter", =
on the grounds that they trust their wgchairs and ADs as their =
intermediaries and would rather not be bothered ("you read DISCUSSes so =
I don't have to.") If people don't want to know, I'll defer to that. But =
I think opening up the default helps keep everybody on their toes.


Suzanne


From nobody Fri Sep 26 13:32:03 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0621A0331; Fri, 26 Sep 2014 13:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.2
X-Spam-Level: 
X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, GB_I_LETTER=-2] autolearn=ham
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 Plh-T5r4kgB2; Fri, 26 Sep 2014 13:31:56 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 580311A0330; Fri, 26 Sep 2014 13:31:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: IETF Announcement List 
Subject: IETF 91 - Meeting Information
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140926203156.3819.9222.idtracker@ietfa.amsl.com>
Date: Fri, 26 Sep 2014 13:31:56 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/fYCfbqB4hPybo-6W_knqb-7_QQE
Cc: wgchairs@ietf.org, recentattendees@ietf.org, irsg@irtf.org
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 20:31:58 -0000

91st IETF Meeting
Honolulu, HI, USA
November 9-14, 2014
Host: Cisco
Welcome Reception: NBCUniversal

Meeting venue: Hilton Hawaiian Village:http://www.hiltonhawaiianvillage.com/

PLEASE NOTE: Construction is taking place in the vicinity of the Tapa Tower Monday to Friday between 9:00am and 5:00pm both before and following IETF91. Construction will be stopped over the dates of 10-13 November 2014 and will resume Friday, 14 November 2014, the last day of IETF 91.

Register online at: http://www.ietf.org/meetings/91/

1.  Registration
2.  Visas & Letters of Invitation
3.  Accommodations
4.  Companion Program
5.  IETF 91 Wiki


1. Registration
   A. Early-Bird Registration - USD 650.00, if paid in full prior to 23:59 UTC 31 October 2014.
   B. After Early-Bird cutoff - USD 800.00
   C. Full-time Student Registrations - USD 150.00 (with proper ID)
   D. One Day Pass Registration - USD 350.00
   E. Registration Cancellation   
        Cut-off for registration cancellation is Monday,
        03 November 2014 at UTC 23:59.
        Cancellations are subject to a 10% (ten percent)
        cancellation fee if requested by that date and time.
   F. Online Registration and Payment ends Friday, 07 November 2014, 1700 local Honolulu time.
   G. On-site Registration starting Sunday, 09 November 2014 at 1100 local Hawaii time.

2. Visas & Letters of Invitation:
   Information on Visiting the United States, please visit:
   http://travel.state.gov/content/travel/english.html

   After you complete the registration process, you can request an electronic IETF letter of invitation as well. The registration system also allows for you to request a hard copy IETF letter of invitation. You may also request one at a later time by following the link provided in the confirmation email.

   Please note that the IETF Letter of Invitation may not be sufficient for obtaining a visa to enter the United States.

3.  Accommodations
   The Hilton Hawaiian Village is currently fully booked. We are in the process of negotiating overflow rooms at a nearby hotel and expect to announce the details next week.

   For information on rooms available pre or post IETF91 at other Hilton properties in Hawaii, please visit: http://www.ietf.org/meeting/91/hotel.html The cutoff for making a reservation is fast approaching!

4.  Companion Program
   If you are traveling with a friend or family member over 18 years of age you can register them for the IETF Companion Program for only USD 25.00

   Benefits include:
   - A special welcome reception for companions from 1630-1730 on Sunday, 09 November
   - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 09 November
   - A distinctive meeting badge that grants access to the venue (not to be used to attend working sessions)
   - Participation in a separate companion email list if you choose to communicate and make plans with other IETF Companions.

   You can register your companion at any time via the IETF website through the "Attendee Self-Service Portal" athttps://www.ietf.org/registration/ietf91/selfservice.py or onsite at the meeting.

   A companion may join the 91 Companions mailing list without any cost at:
https://www.ietf.org/mailman/listinfo/91companions

5.  IETF 91 Wiki
   The IETF 91 meeting wiki (Your Wiki) has been created for the attendees of IETF 91 meeting to exchange information.

   Your IETF 91 (Hawaii) wiki can be found here:
http://www.ietf.org/registration/MeetingWiki/wiki/ietf91
and is also accessible from the Toronto meeting page on the IETF website.

   If you are registered for IETF 91, a user account has been automatically created for you on this Wiki. Your user name is the email address you registered under, and your initial password is your 10 digit confirmation number. You can change your password in your profile settings. 

Only 43 days until the Hawaii IETF!


From nobody Fri Sep 26 14:23:49 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B624C1A1A6C; Fri, 26 Sep 2014 12:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 ANWGXgbBo-Iu; Fri, 26 Sep 2014 12:28:54 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D351A00B2; Fri, 26 Sep 2014 12:28:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: IETF Administrative Director 
To: IETF Announcement List 
Subject: Lawsuit Names ISOC & IETF:  Glassey v. MicroSemi Inc.
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140926192854.2989.84259.idtracker@ietfa.amsl.com>
Date: Fri, 26 Sep 2014 12:28:54 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/WmlumO-HRoOIGStKJNtQTgarJRM
X-Mailman-Approved-At: Fri, 26 Sep 2014 14:23:36 -0700
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 19:28:55 -0000

On September 4th the Internet Society was served a complaint in a lawsuit titled "Todd S. 
Glassey vs MicroSemi Inc.” The complaint names, among others, the Internet Society and 
the IETF.  

The complaint  
as well as a motion to dismiss  
the complaint, which was filed on behalf of the Internet Society and the IETF 
on September 25th, are published here in the name of transparency.


We have been advised by our counsel that discussion of the merits of the 
complaint at this stage would be counterproductive, so no Internet Society 
employee or member of the IETF “management” (the IAB, IESG or IAOC) should 
engage in any discussion or answer any questions regarding the complaint or 
the motion while the case is active and we advise that the IETF community also 
refrain from such discussions.

Ray Pelletier
IETF Administrative Director
On Behalf of the IAOC


From nobody Sun Sep 28 20:22:07 2014
Return-Path: 
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDDC1A6F96 for ; Sun, 28 Sep 2014 20:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.603
X-Spam-Level: ***
X-Spam-Status: No, score=3.603 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_16=0.6] autolearn=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 KokOBtQ2SH4d for ; Sun, 28 Sep 2014 20:22:03 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75C41A6F92 for ; Sun, 28 Sep 2014 20:22:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6224BE2034; Sun, 28 Sep 2014 23:22:01 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25461-06; Sun, 28 Sep 2014 23:22:00 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [12.180.137.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 3904DE2031; Sun, 28 Sep 2014 23:21:58 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s8SMhrwG007667; Sun, 28 Sep 2014 18:43:53 -0400
From: Derek Atkins 
To: Brian E Carpenter 
Subject: Re: [BOFChairs] best practices for dealing with DMARC fallout on IETF lists
References:  <54224924.6080808@cisco.com>  <54224DB1.9030607@cisco.com> <11835.1411566784@sandelman.ca>   <54237403.5040602@gmail.com>
Date: Sun, 28 Sep 2014 18:43:53 -0400
In-Reply-To: <54237403.5040602@gmail.com> (Brian E. Carpenter's message of "Thu, 25 Sep 2014 13:46:43 +1200")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: http://mailarchive.ietf.org/arch/msg/wgchairs/UrtmsDjxk5RXw8JOVvkxrLj4yg8
Cc: Michael Richardson , WG Chairs 
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Working Group Chairs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Sep 2014 03:22:04 -0000

Brian,

Brian E Carpenter  writes:

> You can tune the bounce processing from the mailman admin page;
> the tab is called "Bounce processing" ;-)
>
> I've just applied these settings to a particular list:
>
> Bounce score threshold 20.0 (user is less likely to be disabled)
> Bounce info stale after 1  (bounce history is reset after 1 day)
> You are disabled warnings 100 (user is highly unlikely to be auto-deleted)
>
> That will, I hope, diminish the problem. But people who
> bounce when they see p=reject should be advised not to do
> that (gmail doesn't, but it does quarantine which is already
> a problem) and people who publish p=reject should be advised
> strongly not to do that, if they wish to join IETF lists with
> the present version of mailman.
>
> Unfortunately there's no option to fake the sender if and only
> if the sender's domain publishes p=reject. That would be nice.

I believe that mailman 2.1.18 (and higher) does have such a feature.

-derek

> Regards
>    Brian
-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant