From nobody Fri Feb 3 08:03:22 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B32129BC5 for ; Fri, 3 Feb 2017 08:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsJnARqa6TnA for ; Fri, 3 Feb 2017 08:03:20 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF6212965E for ; Fri, 3 Feb 2017 08:03:20 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v13G2tke028729 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Feb 2017 10:02:56 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Alexey Melnikov" Date: Fri, 03 Feb 2017 10:02:58 -0600 Message-ID: <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> In-Reply-To: References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: Glen , Henrik Levkowetz , tools-development@ietf.org Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:03:21 -0000 (- IESG list ) Hi Henrick, What's the next step(s) here? Are we waiting for the MailMan update to do further investigation, or can some of the uncertainties be answered in the interim? Thanks! Ben. On 24 Jan 2017, at 13:22, Alexey Melnikov wrote: > Hi Henrik, > >> On 23 Jan 2017, at 16:54, Henrik Levkowetz >> wrote: >> >> Hi Alexey, >> >>> On 2017-01-23 12:57, Alexey Melnikov wrote: >>> Dear tools team, >>> >>> The IESG continues to be concerned about the impacts of growing >>> usage of >>> DMARC technology on IETF discussion lists. All choices in front of >>> us, >>> including not taking any action, cause some pain, as we have not >>> been >>> able to identify a perfect approach to mitigate the impacts. >>> >>> The situation is evolving, as email software evolves and new >>> features >>> relating to DMARC also continue to be developed. The IESG believes >>> that >>> we need to be aware of the effects and consider different mitigation >>> approaches. The effects are not necessarily easy to predict based on >>> theoretical analysis, given the wide variety of software and >>> configurations that our participants use, and their personal >>> preferences >>> among important IETF mailing list functions and avoidance of various >>> failure modes. >>> >>> Robert told us that Mailman is due for an upgrade in February. This >>> upgrade would allow IETF to run different IETF mailing lists in >>> different configurations. >> >> I guess this is coupled with upgrading to OpenSUSE 42.x and gives us >> Mailman 2.1.18 (or higher) with the DMARC handling options described >> here: , yes? > > I believe so. > >> https://wiki.list.org/DEV/DMARC >> >>> The IESG would >>> like to perform limited tests on selected lists to determine the >>> impacts >>> of a couple of different possible mitigation configurations. It is >>> important that such an experiment be carefully monitored and that >>> the >>> impacted users be asked about their experiences. There are strong >>> opinions on this matter, but the discussion of this matter has so >>> far >>> involved a small subset of vocal IETFers. What matters more though >>> is >>> the experience of the users as a whole. >>> >>> The two options that IESG would like to test are: From header field >>> rewriting (user@example.com would become an IETF managed forwarding >>> alias, >>> the exact structure is TBD(*)) and message wrapping (encapsulation >>> of >>> original message inside multipart/mixed, with the original message >>> as >>> message/rfc822 attachment + some explanatory text). >>> These workarounds would only apply to email messages from domains >>> that >>> publish DMARC p=reject or p=quarantine policy. Messages from domains >>> that don't publish DMARC policy or have DMARC policy p=none are not >>> affected by this change. >>> >>> In order to figure out which option has less impact on IETF >>> participants, IESG would like to try one of them for a couple of >>> weeks >>> (+ collect feedback), roll back the configuration to the current >>> one, >>> then try the other one (+collect feedback) for a couple of weeks. >>> Each experiment will run on one or more IETF mailing list. >>> >>> In order to achieve this, the IESG would like to do the following: >>> >>> 0) Publish detailed description of how two workarounds are going to >>> work >>> and comparison of their side effects (both positive and negative). >>> >>> 1) Decide with the tools team which mailing lists to use for testing >>> of each option. This will also need to be agreed with >>> managers/working >>> group chairs >>> of the affected mailing lists. >>> >>> 2) Discuss with the tools team what kind of changes (new scripts, >>> reconfiguration, Mailman options) are needed to deploy both of >>> these. >>> Agree on when they can be implemented. Publish the timeline to the >>> wider >>> IETF community. >> >> If the features of Mailman 2.1.18 are insufficient, the start-up time >> (writing new scripts) will be longer than otherwise. This should >> maybe >> be factored into any decision on exactly which options to try out. > > Right. From address rewriting will need some scripting work. John > Levine said that he could help (he done a version in Python for his > mailing list manager, which is not Mailman). > >> FWIW, based on what I can read out of the available mailman 2.1 >> documentation (http://www.list.org/mailman-admin.txt) the From: >> header >> field rewriting considered above isn't supported by mailman directly; >> only replacement of the From: header value with the list address (for >> p=reject or p=quarantine domains) and placement of the original From: >> address in Reply-To:. So it looks as if the rewrite test option >> _will_ >> require both new coding and consideration of where in the email >> pipeline >> the rewrite (and rewrite reversal) should be done. > > Right. > >>> 3) Design with the tools team a detailed plan of what kind of >>> feedback >>> we will be looking for when evaluating results of experimental >>> deployment >>> of each of these options. Notify the IETF community. >>> >>> 4) It might be worth publishing a Wiki page describing how different >>> email clients, email systems can be used or configured to minimize >>> impact of workarounds. >>> >>> Does this look like a reasonable starting plan? >> >> Assuming that we can use mailman 2.1.18 features to do the rewriting/ >> wrapping, then yes, as far as I can see. If new code is required, >> it's >> still reasonable if the time and resources issue is considered. >> >> One more comment below: >> >>> >>> Best Regards, >>> Alexey, on behalf of IESG >>> >>> >>> (*) For example, user@example.com would become user@dmarc.ietf.org >>> and >>> any email sent to user@dmarc.ietf.org would be forwarded to >>> user@example.com. >>> We are still discussing with Email experts how forwarding emails >>> might >>> look >>> like. Some possibilites are u=user.example.com@dmarc.ietf.org, >>> user@example.com.dmarc.ietf.org. >> >> I'm sure the experts will provide a good suggestion. I just note >> that of >> the options above, the 'u=user.example.com@dmarc.ietf.org' variant >> will >> not be able to handle addresses like some.user.name@some.domain.name >> (multiple dots in either localpart or domain -- which dot corresponds >> to >> the at sign when you reverse the address??) well if you expect to do >> the >> reversal without using saved state. > > Right, this was just from the top of head. I don't think we want to > maintain any state for this. Some kind of encoding scheme would be > needed. Possibly replacing @ with %. > > > Best Regards, > Alexey From nobody Fri Feb 3 08:10:22 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DED129660 for ; Fri, 3 Feb 2017 08:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6bLqNhlvOno for ; Fri, 3 Feb 2017 08:10:19 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EF6129BFF for ; Fri, 3 Feb 2017 08:10:15 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v13G9oBn029443 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Feb 2017 10:09:51 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Alexey Melnikov" , Glen Date: Fri, 03 Feb 2017 10:09:53 -0600 Message-ID: <8CB242E9-45B6-43DA-B893-232BC55EE6F5@nostrum.com> In-Reply-To: <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: Henrik Levkowetz , tools-development@ietf.org Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:10:21 -0000 Glen: Are you comfortable with the plan being discussed? Thanks! Ben. On 3 Feb 2017, at 10:02, Ben Campbell wrote: > (- IESG list ) > > Hi Henrick, > > What's the next step(s) here? Are we waiting for the MailMan update to > do further investigation, or can some of the uncertainties be answered > in the interim? > > Thanks! > > Ben. > > On 24 Jan 2017, at 13:22, Alexey Melnikov wrote: > >> Hi Henrik, >> >>> On 23 Jan 2017, at 16:54, Henrik Levkowetz >>> wrote: >>> >>> Hi Alexey, >>> >>>> On 2017-01-23 12:57, Alexey Melnikov wrote: >>>> Dear tools team, >>>> >>>> The IESG continues to be concerned about the impacts of growing >>>> usage of >>>> DMARC technology on IETF discussion lists. All choices in front of >>>> us, >>>> including not taking any action, cause some pain, as we have not >>>> been >>>> able to identify a perfect approach to mitigate the impacts. >>>> >>>> The situation is evolving, as email software evolves and new >>>> features >>>> relating to DMARC also continue to be developed. The IESG believes >>>> that >>>> we need to be aware of the effects and consider different >>>> mitigation >>>> approaches. The effects are not necessarily easy to predict based >>>> on >>>> theoretical analysis, given the wide variety of software and >>>> configurations that our participants use, and their personal >>>> preferences >>>> among important IETF mailing list functions and avoidance of >>>> various >>>> failure modes. >>>> >>>> Robert told us that Mailman is due for an upgrade in February. This >>>> upgrade would allow IETF to run different IETF mailing lists in >>>> different configurations. >>> >>> I guess this is coupled with upgrading to OpenSUSE 42.x and gives us >>> Mailman 2.1.18 (or higher) with the DMARC handling options described >>> here: , yes? >> >> I believe so. >> >>> https://wiki.list.org/DEV/DMARC >>> >>>> The IESG would >>>> like to perform limited tests on selected lists to determine the >>>> impacts >>>> of a couple of different possible mitigation configurations. It is >>>> important that such an experiment be carefully monitored and that >>>> the >>>> impacted users be asked about their experiences. There are strong >>>> opinions on this matter, but the discussion of this matter has so >>>> far >>>> involved a small subset of vocal IETFers. What matters more though >>>> is >>>> the experience of the users as a whole. >>>> >>>> The two options that IESG would like to test are: From header field >>>> rewriting (user@example.com would become an IETF managed forwarding >>>> alias, >>>> the exact structure is TBD(*)) and message wrapping (encapsulation >>>> of >>>> original message inside multipart/mixed, with the original message >>>> as >>>> message/rfc822 attachment + some explanatory text). >>>> These workarounds would only apply to email messages from domains >>>> that >>>> publish DMARC p=reject or p=quarantine policy. Messages from >>>> domains >>>> that don't publish DMARC policy or have DMARC policy p=none are not >>>> affected by this change. >>>> >>>> In order to figure out which option has less impact on IETF >>>> participants, IESG would like to try one of them for a couple of >>>> weeks >>>> (+ collect feedback), roll back the configuration to the current >>>> one, >>>> then try the other one (+collect feedback) for a couple of weeks. >>>> Each experiment will run on one or more IETF mailing list. >>>> >>>> In order to achieve this, the IESG would like to do the following: >>>> >>>> 0) Publish detailed description of how two workarounds are going to >>>> work >>>> and comparison of their side effects (both positive and negative). >>>> >>>> 1) Decide with the tools team which mailing lists to use for >>>> testing >>>> of each option. This will also need to be agreed with >>>> managers/working >>>> group chairs >>>> of the affected mailing lists. >>>> >>>> 2) Discuss with the tools team what kind of changes (new scripts, >>>> reconfiguration, Mailman options) are needed to deploy both of >>>> these. >>>> Agree on when they can be implemented. Publish the timeline to the >>>> wider >>>> IETF community. >>> >>> If the features of Mailman 2.1.18 are insufficient, the start-up >>> time >>> (writing new scripts) will be longer than otherwise. This should >>> maybe >>> be factored into any decision on exactly which options to try out. >> >> Right. From address rewriting will need some scripting work. John >> Levine said that he could help (he done a version in Python for his >> mailing list manager, which is not Mailman). >> >>> FWIW, based on what I can read out of the available mailman 2.1 >>> documentation (http://www.list.org/mailman-admin.txt) the From: >>> header >>> field rewriting considered above isn't supported by mailman >>> directly; >>> only replacement of the From: header value with the list address >>> (for >>> p=reject or p=quarantine domains) and placement of the original >>> From: >>> address in Reply-To:. So it looks as if the rewrite test option >>> _will_ >>> require both new coding and consideration of where in the email >>> pipeline >>> the rewrite (and rewrite reversal) should be done. >> >> Right. >> >>>> 3) Design with the tools team a detailed plan of what kind of >>>> feedback >>>> we will be looking for when evaluating results of experimental >>>> deployment >>>> of each of these options. Notify the IETF community. >>>> >>>> 4) It might be worth publishing a Wiki page describing how >>>> different >>>> email clients, email systems can be used or configured to minimize >>>> impact of workarounds. >>>> >>>> Does this look like a reasonable starting plan? >>> >>> Assuming that we can use mailman 2.1.18 features to do the >>> rewriting/ >>> wrapping, then yes, as far as I can see. If new code is required, >>> it's >>> still reasonable if the time and resources issue is considered. >>> >>> One more comment below: >>> >>>> >>>> Best Regards, >>>> Alexey, on behalf of IESG >>>> >>>> >>>> (*) For example, user@example.com would become user@dmarc.ietf.org >>>> and >>>> any email sent to user@dmarc.ietf.org would be forwarded to >>>> user@example.com. >>>> We are still discussing with Email experts how forwarding emails >>>> might >>>> look >>>> like. Some possibilites are u=user.example.com@dmarc.ietf.org, >>>> user@example.com.dmarc.ietf.org. >>> >>> I'm sure the experts will provide a good suggestion. I just note >>> that of >>> the options above, the 'u=user.example.com@dmarc.ietf.org' variant >>> will >>> not be able to handle addresses like some.user.name@some.domain.name >>> (multiple dots in either localpart or domain -- which dot >>> corresponds to >>> the at sign when you reverse the address??) well if you expect to do >>> the >>> reversal without using saved state. >> >> Right, this was just from the top of head. I don't think we want to >> maintain any state for this. Some kind of encoding scheme would be >> needed. Possibly replacing @ with %. >> >> >> Best Regards, >> Alexey From nobody Fri Feb 3 10:10:36 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC874129469 for ; Fri, 3 Feb 2017 10:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYxb1rRg0e-t for ; Fri, 3 Feb 2017 10:10:32 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E56A12945E for ; Fri, 3 Feb 2017 10:10:32 -0800 (PST) Received: from [212.76.253.174] (port=61255 helo=[192.168.43.236]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cZiJa-0007yy-AX; Fri, 03 Feb 2017 10:10:32 -0800 To: Ben Campbell , Alexey Melnikov References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> From: Henrik Levkowetz Message-ID: <5894C795.7020608@levkowetz.com> Date: Fri, 3 Feb 2017 19:10:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GkB8xPruhCedS173kI0mo1arWeCmtRcoq" X-SA-Exim-Connect-IP: 212.76.253.174 X-SA-Exim-Rcpt-To: glen@amsl.com, tools-development@ietf.org, aamelnikov@fastmail.fm, ben@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: Cc: tools-development@ietf.org, Glen Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:10:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GkB8xPruhCedS173kI0mo1arWeCmtRcoq Content-Type: multipart/mixed; boundary="veiW6hDWjumjWXWrVs2113oftEm3OUwc5"; protected-headers="v1" From: Henrik Levkowetz To: Ben Campbell , Alexey Melnikov Cc: tools-development@ietf.org, Glen Message-ID: <5894C795.7020608@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> In-Reply-To: <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> --veiW6hDWjumjWXWrVs2113oftEm3OUwc5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ben, Strawman for next steps: 1. Code snippets from John Levine (via Alexey) 2. Figuring out where in the mail pipeline the rewriting should happen (Glen+Alexey+Robert+Henrik, I think) 3. Figuring out needed glue to use John's snippets (Glen, Henrik) 4. Installation of OpenSUSE 42.x (Glen, Matt) 5. Installation of glue code + snippets in conjunction with community notification about the experiment (Glen, Henrik) Best regards, Henrik On 2017-02-03 17:02, Ben Campbell wrote: > (- IESG list ) >=20 > Hi Henrick, >=20 > What's the next step(s) here? Are we waiting for the MailMan update to = > do further investigation, or can some of the uncertainties be answered = > in the interim? >=20 > Thanks! >=20 > Ben. >=20 > On 24 Jan 2017, at 13:22, Alexey Melnikov wrote: >=20 >> Hi Henrik, >> >>> On 23 Jan 2017, at 16:54, Henrik Levkowetz =20 >>> wrote: >>> >>> Hi Alexey, >>> >>>> On 2017-01-23 12:57, Alexey Melnikov wrote: >>>> Dear tools team, >>>> >>>> The IESG continues to be concerned about the impacts of growing=20 >>>> usage of >>>> DMARC technology on IETF discussion lists. All choices in front of=20 >>>> us, >>>> including not taking any action, cause some pain, as we have not=20 >>>> been >>>> able to identify a perfect approach to mitigate the impacts. >>>> >>>> The situation is evolving, as email software evolves and new=20 >>>> features >>>> relating to DMARC also continue to be developed. The IESG believes=20 >>>> that >>>> we need to be aware of the effects and consider different mitigation= >>>> approaches. The effects are not necessarily easy to predict based on= >>>> theoretical analysis, given the wide variety of software and >>>> configurations that our participants use, and their personal=20 >>>> preferences >>>> among important IETF mailing list functions and avoidance of various= >>>> failure modes. >>>> >>>> Robert told us that Mailman is due for an upgrade in February. This >>>> upgrade would allow IETF to run different IETF mailing lists in >>>> different configurations. >>> >>> I guess this is coupled with upgrading to OpenSUSE 42.x and gives us >>> Mailman 2.1.18 (or higher) with the DMARC handling options described >>> here: , yes? >> >> I believe so. >> >>> https://wiki.list.org/DEV/DMARC >>> >>>> The IESG would >>>> like to perform limited tests on selected lists to determine the=20 >>>> impacts >>>> of a couple of different possible mitigation configurations. It is >>>> important that such an experiment be carefully monitored and that=20 >>>> the >>>> impacted users be asked about their experiences. There are strong >>>> opinions on this matter, but the discussion of this matter has so=20 >>>> far >>>> involved a small subset of vocal IETFers. What matters more though=20 >>>> is >>>> the experience of the users as a whole. >>>> >>>> The two options that IESG would like to test are: From header field >>>> rewriting (user@example.com would become an IETF managed forwarding >>>> alias, >>>> the exact structure is TBD(*)) and message wrapping (encapsulation=20 >>>> of >>>> original message inside multipart/mixed, with the original message=20 >>>> as >>>> message/rfc822 attachment + some explanatory text). >>>> These workarounds would only apply to email messages from domains=20 >>>> that >>>> publish DMARC p=3Dreject or p=3Dquarantine policy. Messages from dom= ains >>>> that don't publish DMARC policy or have DMARC policy p=3Dnone are no= t >>>> affected by this change. >>>> >>>> In order to figure out which option has less impact on IETF >>>> participants, IESG would like to try one of them for a couple of=20 >>>> weeks >>>> (+ collect feedback), roll back the configuration to the current=20 >>>> one, >>>> then try the other one (+collect feedback) for a couple of weeks. >>>> Each experiment will run on one or more IETF mailing list. >>>> >>>> In order to achieve this, the IESG would like to do the following: >>>> >>>> 0) Publish detailed description of how two workarounds are going to = >>>> work >>>> and comparison of their side effects (both positive and negative). >>>> >>>> 1) Decide with the tools team which mailing lists to use for testing= >>>> of each option. This will also need to be agreed with=20 >>>> managers/working >>>> group chairs >>>> of the affected mailing lists. >>>> >>>> 2) Discuss with the tools team what kind of changes (new scripts, >>>> reconfiguration, Mailman options) are needed to deploy both of=20 >>>> these. >>>> Agree on when they can be implemented. Publish the timeline to the=20 >>>> wider >>>> IETF community. >>> >>> If the features of Mailman 2.1.18 are insufficient, the start-up time= >>> (writing new scripts) will be longer than otherwise. This should=20 >>> maybe >>> be factored into any decision on exactly which options to try out. >> >> Right. From address rewriting will need some scripting work. John=20 >> Levine said that he could help (he done a version in Python for his=20 >> mailing list manager, which is not Mailman). >> >>> FWIW, based on what I can read out of the available mailman 2.1 >>> documentation (http://www.list.org/mailman-admin.txt) the From:=20 >>> header >>> field rewriting considered above isn't supported by mailman directly;= >>> only replacement of the From: header value with the list address (for= >>> p=3Dreject or p=3Dquarantine domains) and placement of the original F= rom: >>> address in Reply-To:. So it looks as if the rewrite test option=20 >>> _will_ >>> require both new coding and consideration of where in the email=20 >>> pipeline >>> the rewrite (and rewrite reversal) should be done. >> >> Right. >> >>>> 3) Design with the tools team a detailed plan of what kind of=20 >>>> feedback >>>> we will be looking for when evaluating results of experimental >>>> deployment >>>> of each of these options. Notify the IETF community. >>>> >>>> 4) It might be worth publishing a Wiki page describing how different= >>>> email clients, email systems can be used or configured to minimize >>>> impact of workarounds. >>>> >>>> Does this look like a reasonable starting plan? >>> >>> Assuming that we can use mailman 2.1.18 features to do the rewriting/= >>> wrapping, then yes, as far as I can see. If new code is required,=20 >>> it's >>> still reasonable if the time and resources issue is considered. >>> >>> One more comment below: >>> >>>> >>>> Best Regards, >>>> Alexey, on behalf of IESG >>>> >>>> >>>> (*) For example, user@example.com would become user@dmarc.ietf.org=20 >>>> and >>>> any email sent to user@dmarc.ietf.org would be forwarded to >>>> user@example.com. >>>> We are still discussing with Email experts how forwarding emails=20 >>>> might >>>> look >>>> like. Some possibilites are u=3Duser.example.com@dmarc.ietf.org, >>>> user@example.com.dmarc.ietf.org. >>> >>> I'm sure the experts will provide a good suggestion. I just note=20 >>> that of >>> the options above, the 'u=3Duser.example.com@dmarc.ietf.org' variant = >>> will >>> not be able to handle addresses like some.user.name@some.domain.name >>> (multiple dots in either localpart or domain -- which dot corresponds= =20 >>> to >>> the at sign when you reverse the address??) well if you expect to do = >>> the >>> reversal without using saved state. >> >> Right, this was just from the top of head. I don't think we want to=20 >> maintain any state for this. Some kind of encoding scheme would be=20 >> needed. Possibly replacing @ with %. >> >> >> Best Regards, >> Alexey >=20 --veiW6hDWjumjWXWrVs2113oftEm3OUwc5-- --GkB8xPruhCedS173kI0mo1arWeCmtRcoq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYlMeVAAoJEE6bV0uPuxca7woQANLV0qB6ITnvCxLpaFnKTlo9 oRjsYOyKW6EF94swhz/z8Lf88q6gLT37J7Hg3w0yg/eqx+lCbfquWbmMolMFbire giMJr86MZxSYe5Ma1McO56FJRntcrzrf0xabqoondzrjhaWImutIbSX7RtKxmh/c TLa1wxJHzWmXMLhcDUMr5nOxdhTyrNEn3VhBkTGQepJwy2BUr2GAoumUmIMkF7uh j3wzXXrS9AX2kR9nZODCb3jKz8njdCjLRy/fPILxAFDvHbiypKDNpN1Ul82ntNVb su5aOeKjOY9bh1RudZnpKkRbZ0YI/RVRm4hxbakz5NhnLtUko2MC2zCFZFaERgR2 rjN91jVgRFGjQkBpf/39lhyltgNqcakVnYBnRfEMfxHLWyLrNvwlvW+Vxyrvb0iH jbbc2zwV2YAO4xOvesRiPzLt/HjVYFroDdYf5ZrLWZQr22Bgpj4P+QEjW4EwL2y4 EB8pL1FGhTrUdqSP0geMd91LSwqbkBmhxiRQjGKaotWOx0PzL6MdzVUXFJeMkV0w z3U8w0gJ4WUtr5kAJVUmG8GwZ0qvXeGZkz3MLgWR2GU1x0k6kfPdGu4pEYysZMAo 0vRVS7COlMTwS+VDubdzDsm8lygxcerfUQRBubpHDb7diNalS8w+dShqltcc4WbF 70GCvAfnSuCXVRFRKwO3 =FfZh -----END PGP SIGNATURE----- --GkB8xPruhCedS173kI0mo1arWeCmtRcoq-- From nobody Fri Feb 3 10:49:23 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B36D1294D5 for ; Fri, 3 Feb 2017 10:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kqEOyyeJSro for ; Fri, 3 Feb 2017 10:49:20 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212CA129500 for ; Fri, 3 Feb 2017 10:49:10 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 3EDC41E5669 for ; Fri, 3 Feb 2017 10:47:45 -0800 (PST) Received: from mail-ot0-f173.google.com (mail-ot0-f173.google.com [74.125.82.173]) by c8a.amsl.com (Postfix) with ESMTPSA id 0E6711E566C for ; Fri, 3 Feb 2017 10:47:45 -0800 (PST) Received: by mail-ot0-f173.google.com with SMTP id 32so20984461oth.3 for ; Fri, 03 Feb 2017 10:49:09 -0800 (PST) X-Gm-Message-State: AIkVDXLFqJdRb/plL7m1A/E7XaS+6ylSyMPxKSV3j5+Rn9djvte4XMbQBbQg7W60i4U2KBBu4c/Sna9FmzSF5w== X-Received: by 10.157.9.69 with SMTP id 63mr8584420otp.152.1486147749161; Fri, 03 Feb 2017 10:49:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.131.67 with HTTP; Fri, 3 Feb 2017 10:48:48 -0800 (PST) In-Reply-To: <8CB242E9-45B6-43DA-B893-232BC55EE6F5@nostrum.com> References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <8CB242E9-45B6-43DA-B893-232BC55EE6F5@nostrum.com> From: Glen Date: Fri, 3 Feb 2017 10:48:48 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c04f048ac3f4a0547a4bc2e Archived-At: Cc: IETF Tools Development , Henrik Levkowetz , Alexey Melnikov Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:49:22 -0000 --94eb2c04f048ac3f4a0547a4bc2e Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 8:09 AM, Ben Campbell wrote: > Glen: Are you comfortable with the plan being discussed? > Thanks! > Ben. Hi Ben - Thank you very much for thinking of me. I shall try to be brief. It seems to me that Mailman, right now (as of 2.1.16 - and we are running 2.1.17), has two very valid and useful options for handling DMARC.... (1) From address rewriting and (2) Message encapsulation. By providing these options, it seems to me that Mailman has solved enough of the problems surrounding DMARC to ensure that our list messages can be effectively delivered to everyone on our lists, without tripping over DMARC anymore. Mailman has also, self-referentially, made this the "standard behavior" for Mailman - because of the way they did it, they've set their own standard for DMARC handling, and so this is the way "most people will expect" Mailman to work. So, I would suggest that testing those existing options right now could be done without any effort on my part, or the Tools Team's part, or any disruption. Just pick a list and try it out. In contrast, I am gathering that the plan being considered is much more complex, involving scripting, program changes to Mailman, the creation and management of an additional alias database driven by Mailman, and so forth. I cannot speak to the benefits of this path, but with respect to my comfort, this worries me a bit, for several reasons. My first concern is security. Earlier statements were correct: Mailman upgrades on the IETF servers do happen as a part of OS upgrades, and also smaller updates. OpenSuse, as most distros do, pushes major upgrades and minor updates to their users, which are installed automatically as they are released. This brings with it advantages - new features (such as the already-available DMARC header rewriting options) are pushed to us regularly, and security holes are closed pretty quickly by midstream updates. Although the frequency of these updates is low, it is non-zero, and not something I can discount. By going down this path, the IETF is essentially choosing to fork Mailman, and make something new. In order to even preserve the changes that were made, I'll have to remove Mailman from the server repository catalogs, and relocate the system to a different directory structure to avoid accidental overwrites in the future. By severing Mailman in this way, we will no longer receive updates, and upgrades will have to be done, in essence, manually. This means that someone will have to start "watching" Mailman for upgrades, and, at each upgrade step, the Tools Team will have to figure out how their modifications mesh with the Mailman modifications, reapply their patches and changes (possibly with modifications to the patches), test, and then figure some way to deploy. Since my responsibility is operations, the only way this could effectively work for me would be to turn Mailman into something similar to the Datatracker: The modified Mailman should probably be stored in the Tools SVN server, patches written by the Tools Team, tested and approved by the TMC, and deployed to us as SNV checkouts by Henrik. Then, whenever, changes come out, the Tools Team (re)writes the patches, the TMC tests, and I (re)deploy - just as we do with the Datatracker. (And, if there are issues, as there sometimes might be, I can "roll back" to the previous SVN release quickly and cleanly.) If (and, likely, only if) this is what is being considered, then, yes, I am comfortable. The prep and engineering work would be done by the Tools Team, validation by TMC, and deployment by the Secretariat, just as we do with the Datatracker now. I would be fine with that. But if something different is being considered, then I could not assert comfort without knowing more about the intention. For example, if the intent is to just "have someone do the scripting" and then "send me some zips to install and test", without any validation or vetting.... or if the intent would be to have someone modify Mailman in place because "the changes are small" (or whatever), then, no, my response would have to be that I am horribly uncomfortable with that, because, at the end of the day, if we bring in some volunteer (or contractor) do "just hand us something", then anything that goes wrong whilst the system is live, and/or any debugging that may need to happen down the road would fall on me... and potentially bury me. Under those circumstances, I would not be comfortable at all. So, knowing more about the "operations" and deployment intent here would be most helpful. Too long? Didn't read? 1. Why not try what Mailman already offers, first? It's not IETF-perfection, but it might be close enough to satisfy. 2. If not, then please plan carefully, and do this right: Set up a forked Mailman source tree (and you might as well go all the way to 2.1.23, the latest), apply your patches and changes to that, test it thoroughly offline, make it perfect, check it in, and then give me a Datatracker-style SVN checkout that I can structure on the server without risk to any of us. Under either of those two conditions, yes, I would be comfortable. Otherwise, I'd think not. Apologies if I'm confused or off-point (it happens often!), and thank you again for asking me. Glen --94eb2c04f048ac3f4a0547a4bc2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 3, 2017 at 8:09 AM, Ben Ca= mpbell <ben@nostrum.com> wrote= :
> Glen: Are you comfortable with the plan being discussed?
> = Thanks!
> Ben.

Hi Ben -

Thank you very much= for thinking of me.=C2=A0 I shall try to be brief.

It se= ems to me that Mailman, right now (as of 2.1.16 - and we are running 2.1.17= ), has two very valid and useful options for handling DMARC....=C2=A0=C2=A0= (1)=C2=A0 From address rewriting and (2) Message encapsulation.=C2=A0=C2= =A0=C2=A0 By providing these options, it seems to me that Mailman has solve= d enough of the problems surrounding DMARC to ensure that our list messages= can be effectively delivered to everyone on our lists, without tripping ov= er DMARC anymore.=C2=A0 Mailman has also, self-referentially, made this the= "standard behavior" for Mailman - because of the way they did it= , they've set their own standard for DMARC handling, and so this is the= way "most people will expect" Mailman to work.

So, I would suggest that testing those existing options right now could be= done without any effort on my part, or the Tools Team's part, or any d= isruption.=C2=A0 Just pick a list and try it out.

In cont= rast, I am gathering that the plan being considered is much more complex, i= nvolving scripting, program changes to Mailman, the creation and management= of an additional alias database driven by Mailman, and so forth.=C2=A0 I c= annot speak to the benefits of this path, but with respect to my comfort, t= his worries me a bit, for several reasons.

My first conce= rn is security.=C2=A0 Earlier statements were correct:=C2=A0 Mailman upgrad= es on the IETF servers do happen as a part of OS upgrades, and also smaller= updates.=C2=A0 OpenSuse, as most distros do, pushes major upgrades and min= or updates to their users, which are installed automatically as they are re= leased.=C2=A0 This brings with it advantages - new features (such as the al= ready-available DMARC header rewriting options) are pushed to us regularly,= and security holes are closed pretty quickly by midstream updates.=C2=A0 A= lthough the frequency of these updates is low, it is non-zero, and not some= thing I can discount.

By going down this path, the IETF i= s essentially choosing to fork Mailman, and make something new.=C2=A0 In or= der to even preserve the changes that were made, I'll have to remove Ma= ilman from the server repository catalogs, and relocate the system to a dif= ferent directory structure to avoid accidental overwrites in the future.=C2= =A0 By severing Mailman in this way, we will no longer receive updates, and= upgrades will have to be done, in essence, manually.=C2=A0 This means that= someone will have to start "watching" Mailman for upgrades, and,= at each upgrade step, the Tools Team will have to figure out how their mod= ifications mesh with the Mailman modifications, reapply their patches and c= hanges (possibly with modifications to the patches), test, and then figure = some way to deploy.

Since my responsibility is operations= , the only way this could effectively work for me would be to turn Mailman = into something similar to the Datatracker:=C2=A0 The modified Mailman shoul= d probably be stored in the Tools SVN server, patches written by the Tools = Team, tested and approved by the TMC, and deployed to us as SNV checkouts b= y Henrik.=C2=A0 Then, whenever, changes come out, the Tools Team (re)writes= the patches, the TMC tests, and I (re)deploy - just as we do with the Data= tracker.=C2=A0 (And, if there are issues, as there sometimes might be, I ca= n "roll back" to the previous SVN release quickly and cleanly.)
If (and, likely, only if) this is what is being considered= , then, yes, I am comfortable.=C2=A0 The prep and engineering work would be= done by the Tools Team, validation by TMC, and deployment by the Secretari= at, just as we do with the Datatracker now.=C2=A0 I would be fine with that= .

But if something different is being considered, then I = could not assert comfort without knowing more about the intention.=C2=A0 Fo= r example, if the intent is to just "have someone do the scripting&quo= t; and then "send me some zips to install and test", without any = validation or vetting.... or if the intent would be to have someone modify= =C2=A0 Mailman in place because "the changes are small" (or whate= ver), then, no, my response would have to be that I am horribly uncomfortab= le with that, because, at the end of the day, if we bring in some volunteer= (or contractor) do "just hand us something", then anything that = goes wrong whilst the system is live, and/or any debugging that may need to= happen down the road would fall on me... and potentially bury me.

<= /div>
Under those circumstances, I would not be comfortable at all.=C2= =A0 So, knowing more about the "operations" and deployment intent= here would be most helpful.

Too long?=C2=A0 D= idn't read?

1. Why not try what Mailman already offer= s, first?=C2=A0 It's not IETF-perfection, but it might be close enough = to satisfy.

2. If not, then please plan carefully, and do= this right:=C2=A0 Set up a forked Mailman source tree (and you might as we= ll go all the way to 2.1.23, the latest), apply your patches and changes to= that, test it thoroughly offline, make it perfect, check it in, and then g= ive me a Datatracker-style SVN checkout that I can structure on the server = without risk to any of us.

Under either of those two cond= itions, yes, I would be comfortable.=C2=A0 Otherwise, I'd think not.
Apologies if I'm confused or off-point (it happens ofte= n!), and thank you again for asking me.

Glen




--94eb2c04f048ac3f4a0547a4bc2e-- From nobody Fri Feb 3 10:52:41 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428CA129496 for ; Fri, 3 Feb 2017 10:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2d2ZAU1bU7L for ; Fri, 3 Feb 2017 10:52:39 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448461294C8 for ; Fri, 3 Feb 2017 10:52:39 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 5AF381E5664 for ; Fri, 3 Feb 2017 10:51:14 -0800 (PST) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by c8a.amsl.com (Postfix) with ESMTPSA id 37B831E5669 for ; Fri, 3 Feb 2017 10:51:14 -0800 (PST) Received: by mail-oi0-f49.google.com with SMTP id u143so16207929oif.3 for ; Fri, 03 Feb 2017 10:52:39 -0800 (PST) X-Gm-Message-State: AIkVDXK+hNEd5iQc2WZnjTF7IJgAPXo50TiEH/VYmoA52gL6V3XzAFkTin0qKFZgaKfj12JQI8Fbr+Eep2cUlA== X-Received: by 10.202.8.197 with SMTP id 188mr8082329oii.22.1486147958536; Fri, 03 Feb 2017 10:52:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.131.67 with HTTP; Fri, 3 Feb 2017 10:52:18 -0800 (PST) In-Reply-To: <5894C795.7020608@levkowetz.com> References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> From: Glen Date: Fri, 3 Feb 2017 10:52:18 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Henrik Levkowetz Content-Type: multipart/alternative; boundary=94eb2c1305722708b90547a4c9d1 Archived-At: Cc: IETF Tools Development , Alexey Melnikov Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:52:40 -0000 --94eb2c1305722708b90547a4c9d1 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 10:10 AM, Henrik Levkowetz wrote: > Hi Ben, > Strawman for next steps: > 1. Code snippets from John Levine (via Alexey) > 2. Figuring out where in the mail pipeline the rewriting should happen > (Glen+Alexey+Robert+Henrik, I think) > 3. Figuring out needed glue to use John's snippets (Glen, Henrik) > 4. Installation of OpenSUSE 42.x (Glen, Matt) > 5. Installation of glue code + snippets in conjunction with community > notification about the experiment (Glen, Henrik) > Best regards, > Henrik Disclaimer: My email was sent before I saw this - I was not ignoring it, I just hadn't seen it. I think my email might change this strawman significantly, but I will defer to Henrik and the rest of you on sorting that out. Glen --94eb2c1305722708b90547a4c9d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 3, 2017 at 10:10 AM, Henrik Lev= kowetz <henrik@levkowetz.com= > wrote:
> Hi Ben,
> Strawman for next steps:
> 1. Cod= e snippets from John Levine (via Alexey)
> 2. Figuring out where in t= he mail pipeline the rewriting should happen
> =C2=A0 =C2=A0(Glen+Ale= xey+Robert+Henrik, I think)
> 3. Figuring out needed glue to use John= 's snippets (Glen, Henrik)
> 4. Installation of OpenSUSE 42.x (Gl= en, Matt)
> 5. Installation of glue code + snippets in conjunction wi= th community
> =C2=A0 =C2=A0notification about the experiment (Glen, = Henrik)
> Best regards,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik
Disclaimer:

My email was sent before I saw this - I= was not ignoring it, I just hadn't seen it.=C2=A0 I think my email mig= ht change this strawman significantly, but I will defer to Henrik and the r= est of you on sorting that out.

Glen

--94eb2c1305722708b90547a4c9d1-- From nobody Fri Feb 3 13:51:24 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD812952D for ; Fri, 3 Feb 2017 13:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUfy75i2Cpnt for ; Fri, 3 Feb 2017 13:51:20 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45DA1294F5 for ; Fri, 3 Feb 2017 13:51:20 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v13Lp1sA059720 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Feb 2017 15:51:02 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: Glen Date: Fri, 03 Feb 2017 15:51:04 -0600 Message-ID: <3B7FD5CE-5C9C-4BF4-A352-15F04961F3D2@nostrum.com> In-Reply-To: References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <8CB242E9-45B6-43DA-B893-232BC55EE6F5@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_FA281CFB-6216-4453-9E98-E2ECD0D1E14C_=" Embedded-HTML: [{"HTML":[831, 6016], "plain":[435, 5503], "uuid":"77EF73D3-597E-4778-8D39-103A2776BC40"}] X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: IETF Tools Development , Henrik Levkowetz , Alexey Melnikov Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:51:23 -0000 --=_MailMate_FA281CFB-6216-4453-9E98-E2ECD0D1E14C_= Content-Type: text/plain; format=flowed I'm sensitive to the concern about forking MailMan from the distro version. Am I correct to assume the existing From: rewriting capability is the limited version that Henrik mentioned? That is, are we agreed that code changes are required for the plan that Alexey described? (Not to question Henrik--I just want to make sure we are all on the same page.) Thanks! Ben (As IESG tools liaison). On 3 Feb 2017, at 12:48, Glen wrote: > On Fri, Feb 3, 2017 at 8:09 AM, Ben Campbell wrote: >> Glen: Are you comfortable with the plan being discussed? >> Thanks! >> Ben. > > Hi Ben - > > Thank you very much for thinking of me. I shall try to be brief. > > It seems to me that Mailman, right now (as of 2.1.16 - and we are > running > 2.1.17), has two very valid and useful options for handling DMARC.... > (1) From address rewriting and (2) Message encapsulation. By > providing > these options, it seems to me that Mailman has solved enough of the > problems surrounding DMARC to ensure that our list messages can be > effectively delivered to everyone on our lists, without tripping over > DMARC > anymore. Mailman has also, self-referentially, made this the > "standard > behavior" for Mailman - because of the way they did it, they've set > their > own standard for DMARC handling, and so this is the way "most people > will > expect" Mailman to work. > > So, I would suggest that testing those existing options right now > could be > done without any effort on my part, or the Tools Team's part, or any > disruption. Just pick a list and try it out. > > In contrast, I am gathering that the plan being considered is much > more > complex, involving scripting, program changes to Mailman, the creation > and > management of an additional alias database driven by Mailman, and so > forth. I cannot speak to the benefits of this path, but with respect > to my > comfort, this worries me a bit, for several reasons. > > My first concern is security. Earlier statements were correct: > Mailman > upgrades on the IETF servers do happen as a part of OS upgrades, and > also > smaller updates. OpenSuse, as most distros do, pushes major upgrades > and > minor updates to their users, which are installed automatically as > they are > released. This brings with it advantages - new features (such as the > already-available DMARC header rewriting options) are pushed to us > regularly, and security holes are closed pretty quickly by midstream > updates. Although the frequency of these updates is low, it is > non-zero, > and not something I can discount. > > By going down this path, the IETF is essentially choosing to fork > Mailman, > and make something new. In order to even preserve the changes that > were > made, I'll have to remove Mailman from the server repository catalogs, > and > relocate the system to a different directory structure to avoid > accidental > overwrites in the future. By severing Mailman in this way, we will no > longer receive updates, and upgrades will have to be done, in essence, > manually. This means that someone will have to start "watching" > Mailman > for upgrades, and, at each upgrade step, the Tools Team will have to > figure > out how their modifications mesh with the Mailman modifications, > reapply > their patches and changes (possibly with modifications to the > patches), > test, and then figure some way to deploy. > > Since my responsibility is operations, the only way this could > effectively > work for me would be to turn Mailman into something similar to the > Datatracker: The modified Mailman should probably be stored in the > Tools > SVN server, patches written by the Tools Team, tested and approved by > the > TMC, and deployed to us as SNV checkouts by Henrik. Then, whenever, > changes come out, the Tools Team (re)writes the patches, the TMC > tests, and > I (re)deploy - just as we do with the Datatracker. (And, if there are > issues, as there sometimes might be, I can "roll back" to the previous > SVN > release quickly and cleanly.) > > If (and, likely, only if) this is what is being considered, then, yes, > I am > comfortable. The prep and engineering work would be done by the Tools > Team, validation by TMC, and deployment by the Secretariat, just as we > do > with the Datatracker now. I would be fine with that. > > But if something different is being considered, then I could not > assert > comfort without knowing more about the intention. For example, if the > intent is to just "have someone do the scripting" and then "send me > some > zips to install and test", without any validation or vetting.... or if > the > intent would be to have someone modify Mailman in place because "the > changes are small" (or whatever), then, no, my response would have to > be > that I am horribly uncomfortable with that, because, at the end of the > day, > if we bring in some volunteer (or contractor) do "just hand us > something", > then anything that goes wrong whilst the system is live, and/or any > debugging that may need to happen down the road would fall on me... > and > potentially bury me. > > Under those circumstances, I would not be comfortable at all. So, > knowing > more about the "operations" and deployment intent here would be most > helpful. > > Too long? Didn't read? > > 1. Why not try what Mailman already offers, first? It's not > IETF-perfection, but it might be close enough to satisfy. > > 2. If not, then please plan carefully, and do this right: Set up a > forked > Mailman source tree (and you might as well go all the way to 2.1.23, > the > latest), apply your patches and changes to that, test it thoroughly > offline, make it perfect, check it in, and then give me a > Datatracker-style > SVN checkout that I can structure on the server without risk to any of > us. > > Under either of those two conditions, yes, I would be comfortable. > Otherwise, I'd think not. > > Apologies if I'm confused or off-point (it happens often!), and thank > you > again for asking me. > > Glen --=_MailMate_FA281CFB-6216-4453-9E98-E2ECD0D1E14C_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I'm sensitive to the concern about forking MailMan from th= e distro version. Am I correct to assume the existing From: rewriting cap= ability is the limited version that Henrik mentioned? That is, are we agr= eed that code changes are required for the plan that Alexey described? (N= ot to question Henrik--I just want to make sure we are all on the same pa= ge.)

Thanks!

Ben (As IESG tools liaison).

On 3 Feb 2017, at 12:48, Glen wrote:

On Fri, Feb 3, 2017 at 8:09 AM, Ben Ca= mpbell <ben@nostrum.com> wro= te:
> Glen: Are you comfortable with the plan being discussed?
&= gt; Thanks!
> Ben.

Hi Ben -

Thank you ver= y much for thinking of me.=C2=A0 I shall try to be brief.

It seems to me that Mailman, right now (as of 2.1.16 - and we are runn= ing 2.1.17), has two very valid and useful options for handling DMARC....= =C2=A0=C2=A0 (1)=C2=A0 From address rewriting and (2) Message encapsulati= on.=C2=A0=C2=A0=C2=A0 By providing these options, it seems to me that Mai= lman has solved enough of the problems surrounding DMARC to ensure that o= ur list messages can be effectively delivered to everyone on our lists, w= ithout tripping over DMARC anymore.=C2=A0 Mailman has also, self-referent= ially, made this the "standard behavior" for Mailman - because = of the way they did it, they've set their own standard for DMARC hand= ling, and so this is the way "most people will expect" Mailman = to work.

So, I would suggest that testing those existin= g options right now could be done without any effort on my part, or the T= ools Team's part, or any disruption.=C2=A0 Just pick a list and try i= t out.

In contrast, I am gathering that the plan being = considered is much more complex, involving scripting, program changes to = Mailman, the creation and management of an additional alias database driv= en by Mailman, and so forth.=C2=A0 I cannot speak to the benefits of this= path, but with respect to my comfort, this worries me a bit, for several= reasons.

My first concern is security.=C2=A0 Earlier s= tatements were correct:=C2=A0 Mailman upgrades on the IETF servers do hap= pen as a part of OS upgrades, and also smaller updates.=C2=A0 OpenSuse, a= s most distros do, pushes major upgrades and minor updates to their users= , which are installed automatically as they are released.=C2=A0 This brin= gs with it advantages - new features (such as the already-available DMARC= header rewriting options) are pushed to us regularly, and security holes= are closed pretty quickly by midstream updates.=C2=A0 Although the frequ= ency of these updates is low, it is non-zero, and not something I can dis= count.

By going down this path, the IETF is essentially= choosing to fork Mailman, and make something new.=C2=A0 In order to even= preserve the changes that were made, I'll have to remove Mailman fro= m the server repository catalogs, and relocate the system to a different = directory structure to avoid accidental overwrites in the future.=C2=A0 B= y severing Mailman in this way, we will no longer receive updates, and up= grades will have to be done, in essence, manually.=C2=A0 This means that = someone will have to start "watching" Mailman for upgrades, and= , at each upgrade step, the Tools Team will have to figure out how their = modifications mesh with the Mailman modifications, reapply their patches = and changes (possibly with modifications to the patches), test, and then = figure some way to deploy.

Since my responsibility is o= perations, the only way this could effectively work for me would be to tu= rn Mailman into something similar to the Datatracker:=C2=A0 The modified = Mailman should probably be stored in the Tools SVN server, patches writte= n by the Tools Team, tested and approved by the TMC, and deployed to us a= s SNV checkouts by Henrik.=C2=A0 Then, whenever, changes come out, the To= ols Team (re)writes the patches, the TMC tests, and I (re)deploy - just a= s we do with the Datatracker.=C2=A0 (And, if there are issues, as there s= ometimes might be, I can "roll back" to the previous SVN releas= e quickly and cleanly.)

If (and, likely, only if) this = is what is being considered, then, yes, I am comfortable.=C2=A0 The prep = and engineering work would be done by the Tools Team, validation by TMC, = and deployment by the Secretariat, just as we do with the Datatracker now= =2E=C2=A0 I would be fine with that.

But if something d= ifferent is being considered, then I could not assert comfort without kno= wing more about the intention.=C2=A0 For example, if the intent is to jus= t "have someone do the scripting" and then "send me some z= ips to install and test", without any validation or vetting.... or i= f the intent would be to have someone modify=C2=A0 Mailman in place becau= se "the changes are small" (or whatever), then, no, my response= would have to be that I am horribly uncomfortable with that, because, at= the end of the day, if we bring in some volunteer (or contractor) do &qu= ot;just hand us something", then anything that goes wrong whilst the= system is live, and/or any debugging that may need to happen down the ro= ad would fall on me... and potentially bury me.

Under t= hose circumstances, I would not be comfortable at all.=C2=A0 So, knowing = more about the "operations" and deployment intent here would be= most helpful.

Too long?=C2=A0 Didn't re= ad?

1. Why not try what Mailman already offers, first?=C2= =A0 It's not IETF-perfection, but it might be close enough to satisfy= =2E

2. If not, then please plan carefully, and do this = right:=C2=A0 Set up a forked Mailman source tree (and you might as well g= o all the way to 2.1.23, the latest), apply your patches and changes to t= hat, test it thoroughly offline, make it perfect, check it in, and then g= ive me a Datatracker-style SVN checkout that I can structure on the serve= r without risk to any of us.

Under either of those two = conditions, yes, I would be comfortable.=C2=A0 Otherwise, I'd think n= ot.

Apologies if I'm confused or off-point (it happ= ens often!), and thank you again for asking me.

Glen



--=_MailMate_FA281CFB-6216-4453-9E98-E2ECD0D1E14C_=-- From nobody Fri Feb 3 14:02:32 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11F61297BD for ; Fri, 3 Feb 2017 14:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N788_tBdYGnf for ; Fri, 3 Feb 2017 14:02:27 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200D8129505 for ; Fri, 3 Feb 2017 14:02:27 -0800 (PST) Received: from unnumerable.local ([47.186.22.210]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v13M2DnY060600 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 3 Feb 2017 16:02:14 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.22.210] claimed to be unnumerable.local To: Ben Campbell , Glen References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <8CB242E9-45B6-43DA-B893-232BC55EE6F5@nostrum.com> <3B7FD5CE-5C9C-4BF4-A352-15F04961F3D2@nostrum.com> From: Robert Sparks Message-ID: Date: Fri, 3 Feb 2017 16:02:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <3B7FD5CE-5C9C-4BF4-A352-15F04961F3D2@nostrum.com> Content-Type: multipart/alternative; boundary="------------2BD14F37DDFEA0D3DB8EDDDD" Archived-At: Cc: Alexey Melnikov , IETF Tools Development , Henrik Levkowetz Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 22:02:31 -0000 This is a multi-part message in MIME format. --------------2BD14F37DDFEA0D3DB8EDDDD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Alexey should weigh in with more detail, but the essence is that (extensive) community discussion has already shown that the rewriting functionality that is in mailman is not sufficient on its own. It results in (at least) a corruption of recipient's address books that the community will not accept. The additional rewriting code and the maintenance of the aliases proposed is what is being proposed to solve that problem. Alexey - could you point Glen to a summary of the discussions that show _why_ we can't simply use mailman as distributed, and point out the other consequences I'm sure I've elided? RjS On 2/3/17 3:51 PM, Ben Campbell wrote: > > I'm sensitive to the concern about forking MailMan from the distro > version. Am I correct to assume the existing From: rewriting > capability is the limited version that Henrik mentioned? That is, are > we agreed that code changes are required for the plan that Alexey > described? (Not to question Henrik--I just want to make sure we are > all on the same page.) > > Thanks! > > Ben (As IESG tools liaison). > > On 3 Feb 2017, at 12:48, Glen wrote: > > On Fri, Feb 3, 2017 at 8:09 AM, Ben Campbell > wrote: > > Glen: Are you comfortable with the plan being discussed? > > Thanks! > > Ben. > > Hi Ben - > > Thank you very much for thinking of me. I shall try to be brief. > > It seems to me that Mailman, right now (as of 2.1.16 - and we are > running 2.1.17), has two very valid and useful options for > handling DMARC.... (1) From address rewriting and (2) Message > encapsulation. By providing these options, it seems to me that > Mailman has solved enough of the problems surrounding DMARC to > ensure that our list messages can be effectively delivered to > everyone on our lists, without tripping over DMARC anymore. > Mailman has also, self-referentially, made this the "standard > behavior" for Mailman - because of the way they did it, they've > set their own standard for DMARC handling, and so this is the way > "most people will expect" Mailman to work. > > So, I would suggest that testing those existing options right now > could be done without any effort on my part, or the Tools Team's > part, or any disruption. Just pick a list and try it out. > > In contrast, I am gathering that the plan being considered is much > more complex, involving scripting, program changes to Mailman, the > creation and management of an additional alias database driven by > Mailman, and so forth. I cannot speak to the benefits of this > path, but with respect to my comfort, this worries me a bit, for > several reasons. > > My first concern is security. Earlier statements were correct: > Mailman upgrades on the IETF servers do happen as a part of OS > upgrades, and also smaller updates. OpenSuse, as most distros do, > pushes major upgrades and minor updates to their users, which are > installed automatically as they are released. This brings with it > advantages - new features (such as the already-available DMARC > header rewriting options) are pushed to us regularly, and security > holes are closed pretty quickly by midstream updates. Although > the frequency of these updates is low, it is non-zero, and not > something I can discount. > > By going down this path, the IETF is essentially choosing to fork > Mailman, and make something new. In order to even preserve the > changes that were made, I'll have to remove Mailman from the > server repository catalogs, and relocate the system to a different > directory structure to avoid accidental overwrites in the future. > By severing Mailman in this way, we will no longer receive > updates, and upgrades will have to be done, in essence, manually. > This means that someone will have to start "watching" Mailman for > upgrades, and, at each upgrade step, the Tools Team will have to > figure out how their modifications mesh with the Mailman > modifications, reapply their patches and changes (possibly with > modifications to the patches), test, and then figure some way to > deploy. > > Since my responsibility is operations, the only way this could > effectively work for me would be to turn Mailman into something > similar to the Datatracker: The modified Mailman should probably > be stored in the Tools SVN server, patches written by the Tools > Team, tested and approved by the TMC, and deployed to us as SNV > checkouts by Henrik. Then, whenever, changes come out, the Tools > Team (re)writes the patches, the TMC tests, and I (re)deploy - > just as we do with the Datatracker. (And, if there are issues, as > there sometimes might be, I can "roll back" to the previous SVN > release quickly and cleanly.) > > If (and, likely, only if) this is what is being considered, then, > yes, I am comfortable. The prep and engineering work would be > done by the Tools Team, validation by TMC, and deployment by the > Secretariat, just as we do with the Datatracker now. I would be > fine with that. > > But if something different is being considered, then I could not > assert comfort without knowing more about the intention. For > example, if the intent is to just "have someone do the scripting" > and then "send me some zips to install and test", without any > validation or vetting.... or if the intent would be to have > someone modify Mailman in place because "the changes are small" > (or whatever), then, no, my response would have to be that I am > horribly uncomfortable with that, because, at the end of the day, > if we bring in some volunteer (or contractor) do "just hand us > something", then anything that goes wrong whilst the system is > live, and/or any debugging that may need to happen down the road > would fall on me... and potentially bury me. > > Under those circumstances, I would not be comfortable at all. So, > knowing more about the "operations" and deployment intent here > would be most helpful. > > Too long? Didn't read? > > 1. Why not try what Mailman already offers, first? It's not > IETF-perfection, but it might be close enough to satisfy. > > 2. If not, then please plan carefully, and do this right: Set up > a forked Mailman source tree (and you might as well go all the way > to 2.1.23, the latest), apply your patches and changes to that, > test it thoroughly offline, make it perfect, check it in, and then > give me a Datatracker-style SVN checkout that I can structure on > the server without risk to any of us. > > Under either of those two conditions, yes, I would be > comfortable. Otherwise, I'd think not. > > Apologies if I'm confused or off-point (it happens often!), and > thank you again for asking me. > > Glen > > > > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --------------2BD14F37DDFEA0D3DB8EDDDD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Alexey should weigh in with more detail, but the essence is that (extensive) community discussion has already shown that the rewriting functionality that is in mailman is not sufficient on its own. It results in (at least) a corruption of recipient's address books that the community will not accept. The additional rewriting code and the maintenance of the aliases proposed is what is being proposed to solve that problem.

Alexey - could you point Glen to a summary of the discussions that show _why_ we can't simply use mailman as distributed, and point out the other consequences I'm sure I've elided?

RjS


On 2/3/17 3:51 PM, Ben Campbell wrote:

I'm sensitive to the concern about forking MailMan from the distro version. Am I correct to assume the existing From: rewriting capability is the limited version that Henrik mentioned? That is, are we agreed that code changes are required for the plan that Alexey described? (Not to question Henrik--I just want to make sure we are all on the same page.)

Thanks!

Ben (As IESG tools liaison).

On 3 Feb 2017, at 12:48, Glen wrote:

On Fri, Feb 3, 2017 at 8:09 AM, Ben Campbell <ben@nostrum.com> wrote:
> Glen: Are you comfortable with the plan being discussed?
> Thanks!
> Ben.

Hi Ben -

Thank you very much for thinking of me.  I shall try to be brief.

It seems to me that Mailman, right now (as of 2.1.16 - and we are running 2.1.17), has two very valid and useful options for handling DMARC....   (1)  From address rewriting and (2) Message encapsulation.    By providing these options, it seems to me that Mailman has solved enough of the problems surrounding DMARC to ensure that our list messages can be effectively delivered to everyone on our lists, without tripping over DMARC anymore.  Mailman has also, self-referentially, made this the "standard behavior" for Mailman - because of the way they did it, they've set their own standard for DMARC handling, and so this is the way "most people will expect" Mailman to work.

So, I would suggest that testing those existing options right now could be done without any effort on my part, or the Tools Team's part, or any disruption.  Just pick a list and try it out.

In contrast, I am gathering that the plan being considered is much more complex, involving scripting, program changes to Mailman, the creation and management of an additional alias database driven by Mailman, and so forth.  I cannot speak to the benefits of this path, but with respect to my comfort, this worries me a bit, for several reasons.

My first concern is security.  Earlier statements were correct:  Mailman upgrades on the IETF servers do happen as a part of OS upgrades, and also smaller updates.  OpenSuse, as most distros do, pushes major upgrades and minor updates to their users, which are installed automatically as they are released.  This brings with it advantages - new features (such as the already-available DMARC header rewriting options) are pushed to us regularly, and security holes are closed pretty quickly by midstream updates.  Although the frequency of these updates is low, it is non-zero, and not something I can discount.

By going down this path, the IETF is essentially choosing to fork Mailman, and make something new.  In order to even preserve the changes that were made, I'll have to remove Mailman from the server repository catalogs, and relocate the system to a different directory structure to avoid accidental overwrites in the future.  By severing Mailman in this way, we will no longer receive updates, and upgrades will have to be done, in essence, manually.  This means that someone will have to start "watching" Mailman for upgrades, and, at each upgrade step, the Tools Team will have to figure out how their modifications mesh with the Mailman modifications, reapply their patches and changes (possibly with modifications to the patches), test, and then figure some way to deploy.

Since my responsibility is operations, the only way this could effectively work for me would be to turn Mailman into something similar to the Datatracker:  The modified Mailman should probably be stored in the Tools SVN server, patches written by the Tools Team, tested and approved by the TMC, and deployed to us as SNV checkouts by Henrik.  Then, whenever, changes come out, the Tools Team (re)writes the patches, the TMC tests, and I (re)deploy - just as we do with the Datatracker.  (And, if there are issues, as there sometimes might be, I can "roll back" to the previous SVN release quickly and cleanly.)

If (and, likely, only if) this is what is being considered, then, yes, I am comfortable.  The prep and engineering work would be done by the Tools Team, validation by TMC, and deployment by the Secretariat, just as we do with the Datatracker now.  I would be fine with that.

But if something different is being considered, then I could not assert comfort without knowing more about the intention.  For example, if the intent is to just "have someone do the scripting" and then "send me some zips to install and test", without any validation or vetting.... or if the intent would be to have someone modify  Mailman in place because "the changes are small" (or whatever), then, no, my response would have to be that I am horribly uncomfortable with that, because, at the end of the day, if we bring in some volunteer (or contractor) do "just hand us something", then anything that goes wrong whilst the system is live, and/or any debugging that may need to happen down the road would fall on me... and potentially bury me.

Under those circumstances, I would not be comfortable at all.  So, knowing more about the "operations" and deployment intent here would be most helpful.

Too long?  Didn't read?

1. Why not try what Mailman already offers, first?  It's not IETF-perfection, but it might be close enough to satisfy.

2. If not, then please plan carefully, and do this right:  Set up a forked Mailman source tree (and you might as well go all the way to 2.1.23, the latest), apply your patches and changes to that, test it thoroughly offline, make it perfect, check it in, and then give me a Datatracker-style SVN checkout that I can structure on the server without risk to any of us.

Under either of those two conditions, yes, I would be comfortable.  Otherwise, I'd think not.

Apologies if I'm confused or off-point (it happens often!), and thank you again for asking me.

Glen






_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development

--------------2BD14F37DDFEA0D3DB8EDDDD-- From nobody Fri Feb 3 14:10:12 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79401299D4 for ; Fri, 3 Feb 2017 14:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fh5oe0WEGKr3 for ; Fri, 3 Feb 2017 14:10:09 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63DC1299CF for ; Fri, 3 Feb 2017 14:10:08 -0800 (PST) Received: from [212.76.253.174] (port=22614 helo=[192.168.43.236]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cZm3R-0000YN-JR; Fri, 03 Feb 2017 14:10:07 -0800 To: glen@amsl.com, Ben Campbell References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <8CB242E9-45B6-43DA-B893-232BC55EE6F5@nostrum.com> From: Henrik Levkowetz Message-ID: <5894FFB5.5080006@levkowetz.com> Date: Fri, 3 Feb 2017 23:09:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q9b0FC6mdrAJa7iHAvWaJ9MfO2I00b77e" X-SA-Exim-Connect-IP: 212.76.253.174 X-SA-Exim-Rcpt-To: tools-development@ietf.org, aamelnikov@fastmail.fm, ben@nostrum.com, glen@amsl.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: Cc: IETF Tools Development , Alexey Melnikov Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 22:10:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q9b0FC6mdrAJa7iHAvWaJ9MfO2I00b77e Content-Type: multipart/mixed; boundary="dafLiVEfQm7wmLeufobmbOT0LC326QInA"; protected-headers="v1" From: Henrik Levkowetz To: glen@amsl.com, Ben Campbell Cc: Alexey Melnikov , IETF Tools Development Message-ID: <5894FFB5.5080006@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <8CB242E9-45B6-43DA-B893-232BC55EE6F5@nostrum.com> In-Reply-To: --dafLiVEfQm7wmLeufobmbOT0LC326QInA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Glen, (I saw your later post, but thought I'd respond to what you write below):= My current understanding is as follows (it could be wrong): The IESG wishes to perform 2 experiments on a small number of mailing lists. One of the experiments requires Mailman 2.1.18, because only with that release can the desired settings be applied to individual mailing lists, rather than as a global setting. The other experiment requires a script or script external to Mailman to rewrite some header fields. The rewrite= s will be statelessly reversible, so will not require any database or other= backing store. With these limitations, the experiments makes sense to me, and I think th= ey also fit within the limits you mention below. On my part, I'm happy to modify the ideas I have of how to implement the proposed experiments in any way needed to fit your security and stability= requirements. Best regards, Henrik On 2017-02-03 19:48, Glen wrote: > On Fri, Feb 3, 2017 at 8:09 AM, Ben Campbell wrote: >> Glen: Are you comfortable with the plan being discussed? >> Thanks! >> Ben. >=20 > Hi Ben - >=20 > Thank you very much for thinking of me. I shall try to be brief. >=20 > It seems to me that Mailman, right now (as of 2.1.16 - and we are runni= ng > 2.1.17), has two very valid and useful options for handling DMARC.... > (1) From address rewriting and (2) Message encapsulation. By provid= ing > these options, it seems to me that Mailman has solved enough of the > problems surrounding DMARC to ensure that our list messages can be > effectively delivered to everyone on our lists, without tripping over D= MARC > anymore. Mailman has also, self-referentially, made this the "standard= > behavior" for Mailman - because of the way they did it, they've set the= ir > own standard for DMARC handling, and so this is the way "most people wi= ll > expect" Mailman to work. >=20 > So, I would suggest that testing those existing options right now could= be > done without any effort on my part, or the Tools Team's part, or any > disruption. Just pick a list and try it out. >=20 > In contrast, I am gathering that the plan being considered is much more= > complex, involving scripting, program changes to Mailman, the creation = and > management of an additional alias database driven by Mailman, and so > forth. I cannot speak to the benefits of this path, but with respect t= o my > comfort, this worries me a bit, for several reasons. >=20 > My first concern is security. Earlier statements were correct: Mailma= n > upgrades on the IETF servers do happen as a part of OS upgrades, and al= so > smaller updates. OpenSuse, as most distros do, pushes major upgrades a= nd > minor updates to their users, which are installed automatically as they= are > released. This brings with it advantages - new features (such as the > already-available DMARC header rewriting options) are pushed to us > regularly, and security holes are closed pretty quickly by midstream > updates. Although the frequency of these updates is low, it is non-zer= o, > and not something I can discount. >=20 > By going down this path, the IETF is essentially choosing to fork Mailm= an, > and make something new. In order to even preserve the changes that wer= e > made, I'll have to remove Mailman from the server repository catalogs, = and > relocate the system to a different directory structure to avoid acciden= tal > overwrites in the future. By severing Mailman in this way, we will no > longer receive updates, and upgrades will have to be done, in essence, > manually. This means that someone will have to start "watching" Mailma= n > for upgrades, and, at each upgrade step, the Tools Team will have to fi= gure > out how their modifications mesh with the Mailman modifications, reappl= y > their patches and changes (possibly with modifications to the patches),= > test, and then figure some way to deploy. >=20 > Since my responsibility is operations, the only way this could effectiv= ely > work for me would be to turn Mailman into something similar to the > Datatracker: The modified Mailman should probably be stored in the Too= ls > SVN server, patches written by the Tools Team, tested and approved by t= he > TMC, and deployed to us as SNV checkouts by Henrik. Then, whenever, > changes come out, the Tools Team (re)writes the patches, the TMC tests,= and > I (re)deploy - just as we do with the Datatracker. (And, if there are > issues, as there sometimes might be, I can "roll back" to the previous = SVN > release quickly and cleanly.) >=20 > If (and, likely, only if) this is what is being considered, then, yes, = I am > comfortable. The prep and engineering work would be done by the Tools > Team, validation by TMC, and deployment by the Secretariat, just as we = do > with the Datatracker now. I would be fine with that. >=20 > But if something different is being considered, then I could not assert= > comfort without knowing more about the intention. For example, if the > intent is to just "have someone do the scripting" and then "send me som= e > zips to install and test", without any validation or vetting.... or if = the > intent would be to have someone modify Mailman in place because "the > changes are small" (or whatever), then, no, my response would have to b= e > that I am horribly uncomfortable with that, because, at the end of the = day, > if we bring in some volunteer (or contractor) do "just hand us somethin= g", > then anything that goes wrong whilst the system is live, and/or any > debugging that may need to happen down the road would fall on me... and= > potentially bury me. >=20 > Under those circumstances, I would not be comfortable at all. So, know= ing > more about the "operations" and deployment intent here would be most > helpful. >=20 > Too long? Didn't read? >=20 > 1. Why not try what Mailman already offers, first? It's not > IETF-perfection, but it might be close enough to satisfy. >=20 > 2. If not, then please plan carefully, and do this right: Set up a for= ked > Mailman source tree (and you might as well go all the way to 2.1.23, th= e > latest), apply your patches and changes to that, test it thoroughly > offline, make it perfect, check it in, and then give me a Datatracker-s= tyle > SVN checkout that I can structure on the server without risk to any of = us. >=20 > Under either of those two conditions, yes, I would be comfortable. > Otherwise, I'd think not. >=20 > Apologies if I'm confused or off-point (it happens often!), and thank y= ou > again for asking me. >=20 > Glen >=20 --dafLiVEfQm7wmLeufobmbOT0LC326QInA-- --q9b0FC6mdrAJa7iHAvWaJ9MfO2I00b77e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYlP+1AAoJEE6bV0uPuxca/gwQALMcVfo0YyU+KVzAFfQcNkyG hMkCK3ET6hFMBboMSGp6TMHmMhWboKaqk8v4VPGaXuCz3JjBIQp+elkoCJY17YNJ Sb0JIJYSA5A1tXk5YGInelc6Bpa5OZTj6rKdrVW5fhqghGBdNUkGsaapsbCunmT6 wlj7hiACZbjqQszJVO0myiMecE/nLcDgV2zKzKOFc4B4IMF+ic0+Swcx2MPnhFEl Ma9TI32xSaWUJT6VUHE5GvzSPwpGfEHRITdo9QvvSPrNYvog6prVKPYicsJNR7Gg 7f44A1VwTbBWozJqZHmsmIIhlSXyy+Iu7Qus18Qd6CXoPLmoj9zXoMagVtCXtIoo oe8HX7aBMw/mwKP6rU0isU79RtHbgBk6tkkETCjQwTPCyISn2BzQyn7zeRpNpce/ bc/h0mtfN7Ak689PojKSJ7JZt3e46u8UHHNt6RX6hsQZw2PgWLq+5Lq2XiCcAAAa L2sFDuGoW6HAoET4aPFzMenmO+VVaAYJwk4Go7zkHEHTM7tI5pUl2uXlsunWYLfB 8QopTtgcondg0eeStKYIEV7LQZ/2Ed1PHFrhX3Zd/98EznpOeuUFXVeJy06UF1Uw HmgQUnjPddkxqSB0zIIfjbfN4MG3yMXMRkZdaX+PSG38e/ghWlfnx446o0mw6YuH +4CogKy8NDOunR/HjY9B =7Zrx -----END PGP SIGNATURE----- --q9b0FC6mdrAJa7iHAvWaJ9MfO2I00b77e-- From nobody Fri Feb 3 14:30:59 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F09129736 for ; Fri, 3 Feb 2017 14:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKXJ7ZgqPrtV for ; Fri, 3 Feb 2017 14:30:55 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCE0129431 for ; Fri, 3 Feb 2017 14:30:55 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id C87C21E5671 for ; Fri, 3 Feb 2017 14:29:29 -0800 (PST) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by c8a.amsl.com (Postfix) with ESMTPSA id 953351E5672 for ; Fri, 3 Feb 2017 14:29:29 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id w204so19348586oiw.0 for ; Fri, 03 Feb 2017 14:30:55 -0800 (PST) X-Gm-Message-State: AIkVDXKVqqJj4aQK0ZPyiLEORXiPPgjOnXUAGsmhNxDv7/eoObY5sh3bF9N7UEP+96theoPs7SJmUDLUwDiuKw== X-Received: by 10.202.108.5 with SMTP id h5mr8845888oic.29.1486161054506; Fri, 03 Feb 2017 14:30:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.131.67 with HTTP; Fri, 3 Feb 2017 14:30:34 -0800 (PST) In-Reply-To: References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <8CB242E9-45B6-43DA-B893-232BC55EE6F5@nostrum.com> <3B7FD5CE-5C9C-4BF4-A352-15F04961F3D2@nostrum.com> From: Glen Date: Fri, 3 Feb 2017 14:30:34 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Robert Sparks Content-Type: multipart/alternative; boundary=001a1142dfaebba8f60547a7d549 Archived-At: Cc: Alexey Melnikov , IETF Tools Development , Henrik Levkowetz Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 22:30:57 -0000 --001a1142dfaebba8f60547a7d549 Content-Type: text/plain; charset=UTF-8 Robert, Alexey - There's no need for that, thanks though. Robert's statement is more than sufficient for me. I don't necessarily need to know the "why" in any event - only the "how". :-) That said, if the community will not accept Mailman's default activity, then perhaps it's more appropriate to consider this as a set of patches we should submit back to Mailman. Is the IETF community "special"? Or do their views seem relevant to the larger Mailman user base? If the latter, I would guess that a contribution of the final outcome back to Mailman would be desirable. (And of course doing it that way might eliminate concerns about forking, as our changes would presumably be "Worked in" to the next Mailman release and become mainstream.) Anyway - nobody needs to sell me on anything - I will do my best to support anything regardless of the "Why". :-) Glen On Fri, Feb 3, 2017 at 2:02 PM, Robert Sparks wrote: > Alexey should weigh in with more detail, but the essence is that > (extensive) community discussion has already shown that the rewriting > functionality that is in mailman is not sufficient on its own. It results > in (at least) a corruption of recipient's address books that the community > will not accept. The additional rewriting code and the maintenance of the > aliases proposed is what is being proposed to solve that problem. > > Alexey - could you point Glen to a summary of the discussions that show > _why_ we can't simply use mailman as distributed, and point out the other > consequences I'm sure I've elided? > > RjS > > On 2/3/17 3:51 PM, Ben Campbell wrote: > > I'm sensitive to the concern about forking MailMan from the distro > version. Am I correct to assume the existing From: rewriting capability is > the limited version that Henrik mentioned? That is, are we agreed that code > changes are required for the plan that Alexey described? (Not to question > Henrik--I just want to make sure we are all on the same page.) > > Thanks! > > Ben (As IESG tools liaison). > > On 3 Feb 2017, at 12:48, Glen wrote: > > On Fri, Feb 3, 2017 at 8:09 AM, Ben Campbell wrote: > > Glen: Are you comfortable with the plan being discussed? > > Thanks! > > Ben. > > Hi Ben - > > Thank you very much for thinking of me. I shall try to be brief. > > It seems to me that Mailman, right now (as of 2.1.16 - and we are running > 2.1.17), has two very valid and useful options for handling DMARC.... > (1) From address rewriting and (2) Message encapsulation. By providing > these options, it seems to me that Mailman has solved enough of the > problems surrounding DMARC to ensure that our list messages can be > effectively delivered to everyone on our lists, without tripping over DMARC > anymore. Mailman has also, self-referentially, made this the "standard > behavior" for Mailman - because of the way they did it, they've set their > own standard for DMARC handling, and so this is the way "most people will > expect" Mailman to work. > > So, I would suggest that testing those existing options right now could be > done without any effort on my part, or the Tools Team's part, or any > disruption. Just pick a list and try it out. > > In contrast, I am gathering that the plan being considered is much more > complex, involving scripting, program changes to Mailman, the creation and > management of an additional alias database driven by Mailman, and so > forth. I cannot speak to the benefits of this path, but with respect to my > comfort, this worries me a bit, for several reasons. > > My first concern is security. Earlier statements were correct: Mailman > upgrades on the IETF servers do happen as a part of OS upgrades, and also > smaller updates. OpenSuse, as most distros do, pushes major upgrades and > minor updates to their users, which are installed automatically as they are > released. This brings with it advantages - new features (such as the > already-available DMARC header rewriting options) are pushed to us > regularly, and security holes are closed pretty quickly by midstream > updates. Although the frequency of these updates is low, it is non-zero, > and not something I can discount. > > By going down this path, the IETF is essentially choosing to fork Mailman, > and make something new. In order to even preserve the changes that were > made, I'll have to remove Mailman from the server repository catalogs, and > relocate the system to a different directory structure to avoid accidental > overwrites in the future. By severing Mailman in this way, we will no > longer receive updates, and upgrades will have to be done, in essence, > manually. This means that someone will have to start "watching" Mailman > for upgrades, and, at each upgrade step, the Tools Team will have to figure > out how their modifications mesh with the Mailman modifications, reapply > their patches and changes (possibly with modifications to the patches), > test, and then figure some way to deploy. > > Since my responsibility is operations, the only way this could effectively > work for me would be to turn Mailman into something similar to the > Datatracker: The modified Mailman should probably be stored in the Tools > SVN server, patches written by the Tools Team, tested and approved by the > TMC, and deployed to us as SNV checkouts by Henrik. Then, whenever, > changes come out, the Tools Team (re)writes the patches, the TMC tests, and > I (re)deploy - just as we do with the Datatracker. (And, if there are > issues, as there sometimes might be, I can "roll back" to the previous SVN > release quickly and cleanly.) > > If (and, likely, only if) this is what is being considered, then, yes, I > am comfortable. The prep and engineering work would be done by the Tools > Team, validation by TMC, and deployment by the Secretariat, just as we do > with the Datatracker now. I would be fine with that. > > But if something different is being considered, then I could not assert > comfort without knowing more about the intention. For example, if the > intent is to just "have someone do the scripting" and then "send me some > zips to install and test", without any validation or vetting.... or if the > intent would be to have someone modify Mailman in place because "the > changes are small" (or whatever), then, no, my response would have to be > that I am horribly uncomfortable with that, because, at the end of the day, > if we bring in some volunteer (or contractor) do "just hand us something", > then anything that goes wrong whilst the system is live, and/or any > debugging that may need to happen down the road would fall on me... and > potentially bury me. > > Under those circumstances, I would not be comfortable at all. So, knowing > more about the "operations" and deployment intent here would be most > helpful. > > Too long? Didn't read? > > 1. Why not try what Mailman already offers, first? It's not > IETF-perfection, but it might be close enough to satisfy. > > 2. If not, then please plan carefully, and do this right: Set up a forked > Mailman source tree (and you might as well go all the way to 2.1.23, the > latest), apply your patches and changes to that, test it thoroughly > offline, make it perfect, check it in, and then give me a Datatracker-style > SVN checkout that I can structure on the server without risk to any of us. > > Under either of those two conditions, yes, I would be comfortable. > Otherwise, I'd think not. > > Apologies if I'm confused or off-point (it happens often!), and thank you > again for asking me. > > Glen > > > > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing listTOOLS-DEVELOPMENT@ietf.orghttps://www.ietf.org/mailman/listinfo/tools-development > > > --001a1142dfaebba8f60547a7d549 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robert, Alexey -

The= re's no need for that, thanks though.=C2=A0 Robert's statement is m= ore than sufficient for me.=C2=A0 I don't necessarily need to know the = "why" in any event - only the "how".=C2=A0 :-)

<= /div>That said, if the community will not accept Mailman's default acti= vity, then perhaps it's more appropriate to consider this as a set of p= atches we should submit back to Mailman.=C2=A0 Is the IETF community "= special"?=C2=A0 Or do their views seem relevant to the larger Mailman = user base?=C2=A0 If the latter, I would guess that a contribution of the fi= nal outcome back to Mailman would be desirable.

(And of course= doing it that way might eliminate concerns about forking, as our changes w= ould presumably be "Worked in" to the next Mailman release and be= come mainstream.)

Anyway - nobody needs to sell me on anything= - I will do my best to support anything regardless of the "Why".= =C2=A0 :-)

Glen

On Fri, Feb 3, 2017 at 2:02 PM= , Robert Sparks <rjsparks@nostrum.com> wrote:
=20 =20 =20

Alexey should weigh in with more detail, but the essence is that (extensive) community discussion has already shown that the rewriting functionality that is in mailman is not sufficient on its own. It results in (at least) a corruption of recipient's address books that the community will not accept. The additional rewriting code and the maintenance of the aliases proposed is what is being proposed to solve that problem.

Alexey - could you point Glen to a summary of the discussions that show _why_ we can't simply use mailman as distributed, and point out the other consequences I'm sure I've elided?

RjS


On 2/3/17 3:51 PM, = Ben Campbell wrote:
=20

I'm sensitive to the concern about forking MailMan from the distro version. Am I correct to assume the existing From: rewriting capability is the limited version that Henrik mentioned? That is, are we agreed that code changes are required for the plan that Alexey described? (Not to question Henrik--I just want to make sure we are all on the same page.)

Thanks!

Ben (As IESG tools liaison).

On 3 Feb 2017, at 12:48, Glen wrote:

On Fri, Feb 3, 2017 at 8:09 AM, Ben Campbell <ben@nostrum.com> wrote:
> Glen: Are you comfortable with the plan being discussed?
> Thanks!
> Ben.

Hi Ben -

Thank you very much for thinking of me.=C2=A0 I shall try to be brief.

It seems to me that Mailman, right now (as of 2.1.16 - and we are running 2.1.17), has two very valid and useful options for handling DMARC....=C2=A0=C2= =A0 (1)=C2=A0 From address rewriting and (2) Message encapsulation.=C2=A0=C2=A0=C2=A0 By providing these optio= ns, it seems to me that Mailman has solved enough of the problems surrounding DMARC to ensure that our list messages can be effectively delivered to everyone on our lists, without tripping over DMARC anymore.=C2=A0 Mailman has also, self-referentially, made this the "standard behavior" for Mailman - because of the way they did it, they've set their own standard for DMARC handling= , and so this is the way "most people will expect"= ; Mailman to work.

So, I would suggest that testing those existing options right now could be done without any effort on my part, or the Tools Team's part, or any disruption.= =C2=A0 Just pick a list and try it out.

In contrast, I am gathering that the plan being considered is much more complex, involving scripting, program changes to Mailman, the creation and management of an additional alias database driven by Mailman, and so forth.=C2=A0 I cannot speak to the benefi= ts of this path, but with respect to my comfort, this worries me a bit, for several reasons.

My first concern is security.=C2=A0 Earlier statements were correct:=C2=A0 Mailman upgrades on the IETF servers = do happen as a part of OS upgrades, and also smaller updates.=C2=A0 OpenSuse, as most distros do, pushes major upgrades and minor updates to their users, which are installed automatically as they are released.=C2=A0 This brings with it advantages - new features (such as the already-available DMARC header rewriting options) are pushed to us regularly, and security holes are closed pretty quickly by midstream updates.=C2=A0 Although the frequency of these updates is low, it is non-zero, and not something I can discount.

By going down this path, the IETF is essentially choosing to fork Mailman, and make something new.=C2=A0 I= n order to even preserve the changes that were made, I'll have to remove Mailman from the server repositor= y catalogs, and relocate the system to a different directory structure to avoid accidental overwrites in the future.=C2=A0 By severing Mailman in this way, we wil= l no longer receive updates, and upgrades will have to be done, in essence, manually.=C2=A0 This means that someone will have to start "watching" Mailman f= or upgrades, and, at each upgrade step, the Tools Team will have to figure out how their modifications mesh with the Mailman modifications, reapply their patches and changes (possibly with modifications to the patches), test, and then figure some way to deploy.

Since my responsibility is operations, the only way this could effectively work for me would be to turn Mailman into something similar to the Datatracker:=C2=A0 The modified Mailman should probably be stored in the Tools SVN server, patches written by the Tools Team, tested and approved by the TMC, and deployed to us as SNV checkouts by Henrik.=C2=A0 Then, whenever, changes co= me out, the Tools Team (re)writes the patches, the TMC tests, and I (re)deploy - just as we do with the Datatracker.=C2=A0 (And, if there are issues, as there sometimes might be, I can "roll back" to the pr= evious SVN release quickly and cleanly.)

If (and, likely, only if) this is what is being considered, then, yes, I am comfortable.=C2=A0 The prep a= nd engineering work would be done by the Tools Team, validation by TMC, and deployment by the Secretariat, just as we do with the Datatracker now.=C2=A0 I would be fine with that.

But if something different is being considered, then I could not assert comfort without knowing more about the intention.=C2=A0 For example, if the intent is = to just "have someone do the scripting" and then &= quot;send me some zips to install and test", without any validati= on or vetting.... or if the intent would be to have someone modify=C2=A0 Mailman in place because "the c= hanges are small" (or whatever), then, no, my response woul= d have to be that I am horribly uncomfortable with that, because, at the end of the day, if we bring in some volunteer (or contractor) do "just hand us something= ", then anything that goes wrong whilst the system is live, and/or any debugging that may need to happen down the road would fall on me... and potentially bury me.

Under those circumstances, I would not be comfortable at all.=C2=A0 So, knowing more about the "operations" and deployment intent here would b= e most helpful.

Too long?=C2=A0 Didn't read?

1. Why not try what Mailman already offers, first?=C2= =A0 It's not IETF-perfection, but it might be close enoug= h to satisfy.

2. If not, then please plan carefully, and do this right:=C2=A0 Set up a forked Mailman source tree (and you might as well go all the way to 2.1.23, the latest), apply your patches and changes to that, test it thoroughly offline, make it perfect, check it in, and then give me a Datatracker-style SVN checkout that I can structure on the server without risk to any of us.
Under either of those two conditions, yes, I would be comfortable.=C2=A0 Otherwise, I'd think not.

Apologies if I'm confused or off-point (it happens often!), and thank you again for asking me.

Glen






_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www=
.ietf.org/mailman/listinfo/tools-development


--001a1142dfaebba8f60547a7d549-- From nobody Fri Feb 3 14:41:04 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D791299F2 for ; Fri, 3 Feb 2017 14:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RdEHiX0wcqx for ; Fri, 3 Feb 2017 14:41:02 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1F2129801 for ; Fri, 3 Feb 2017 14:41:02 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 7C3EC1E566E for ; Fri, 3 Feb 2017 14:39:36 -0800 (PST) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by c8a.amsl.com (Postfix) with ESMTPSA id 56A201E566F for ; Fri, 3 Feb 2017 14:39:36 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id u143so19340988oif.3 for ; Fri, 03 Feb 2017 14:41:01 -0800 (PST) X-Gm-Message-State: AIkVDXK2RsPcEqPzy3u2iH8hYcl3LBriVd38T+xeSg3p5x8qGoljURpm6z34dNwFmfkINCvgH2E3geNoeenUiA== X-Received: by 10.202.179.9 with SMTP id c9mr7219935oif.152.1486161661330; Fri, 03 Feb 2017 14:41:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.131.67 with HTTP; Fri, 3 Feb 2017 14:40:40 -0800 (PST) In-Reply-To: <5894FFB5.5080006@levkowetz.com> References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <8CB242E9-45B6-43DA-B893-232BC55EE6F5@nostrum.com> <5894FFB5.5080006@levkowetz.com> From: Glen Date: Fri, 3 Feb 2017 14:40:40 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Henrik Levkowetz Content-Type: multipart/alternative; boundary=001a113ce602e70c4a0547a7f919 Archived-At: Cc: IETF Tools Development , Alexey Melnikov Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 22:41:03 -0000 --001a113ce602e70c4a0547a7f919 Content-Type: text/plain; charset=UTF-8 All - Apologies. My mail volume is high, and I process at intervals, and in linear fashion only, usually. Sorry. Hi Henrik - On Fri, Feb 3, 2017 at 2:09 PM, Henrik Levkowetz wrote: > Hi Glen, > (I saw your later post, but thought I'd respond to what you write below): > My current understanding is as follows (it could be wrong): The IESG > wishes to perform 2 experiments on a small number of mailing lists. > One of the experiments requires Mailman 2.1.18, because only with that > release can the desired settings be applied to individual mailing lists, > rather than as a global setting. The other experiment requires a script > or script external to Mailman to rewrite some header fields. The rewrites > will be statelessly reversible, so will not require any database or other > backing store. This all sounds excellent. So if I understand you, we're not actually patching the Mailman source tree for either of the IETF's desired experiments here. That would mean that we don't have to fork, and my earlier thoughts on SVN, et al, are irrelevant. That would be a much happier outcome for me. > With these limitations, the experiments makes sense to me, and I think they > also fit within the limits you mention below. > On my part, I'm happy to modify the ideas I have of how to implement the > proposed experiments in any way needed to fit your security and stability > requirements. Thank you. If you're comfortable, I'm comfortable, so let's proceed. Here is the situation on my end: We've upgraded Ryan's development server, and the Sandbox server, to OpenSuse 42.2 (the latest, as mentioned previously) which includes Mailman 2.1.22. I'm going to do "ietfc" (the "unofficial second" hot backup machine) this weekend. Ryan and Matt will have that machine starting Monday to test and check. I hope to hear a good report from them soon (within the week) and do "ietfb" (the Orlando/main hot backup) the following weekend, with the same subsequent test and check by them. If all goes well, I will report back to the TMC with a summary of our experiences, and an assumption of readiness, so that we can schedule the production machine. I am guessing, if all goes well, we can do that update live and in place on Monday the 20th, or Monday the 27th, depending on how everything else goes. I hope this answers everything. Thanks to you and Ben and everyone for your support! Best regards, Glen --001a113ce602e70c4a0547a7f919 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All -

Apologies.=C2=A0 My= mail volume is high, and I process at intervals, and in linear fashion onl= y, usually.=C2=A0 Sorry.

Hi Henrik -

On Fri, Feb 3= , 2017 at 2:09 PM, Henrik Levkowetz <henrik@levkowetz.com> wrote:
> Hi Glen,
> (I saw yo= ur later post, but thought I'd respond to what you write below):
>= ; My current understanding is as follows (it could be wrong): The IESG
&= gt; wishes to perform 2 experiments on a small number of mailing lists.
= > One of the experiments requires Mailman 2.1.18, because only with that=
> release can the desired settings be applied to individual mailing = lists,
> rather than as a global setting.=C2=A0 The other experiment = requires a script
> or script external to Mailman to rewrite some hea= der fields.=C2=A0 The rewrites
> will be statelessly reversible, so w= ill not require any database or other
> backing store.

This al= l sounds excellent. So if I understand you, we're not actually=20 patching the Mailman source tree for either of the IETF's desired=20 experiments here.=C2=A0 That would mean that we don't have to fork, and= my=20 earlier thoughts on SVN, et al, are irrelevant.=C2=A0 That would be a much= =20 happier outcome for me.

> With these limitations, the experiments= makes sense to me, and I think they
> also fit within the limits you= mention below.
> On my part, I'm happy to modify the ideas I hav= e of how to implement the
> proposed experiments in any way needed to= fit your security and stability
> requirements.

Thank y= ou.=C2=A0 If you're comfortable, I'm comfortable, so let's proc= eed.

Here is the situation on my end:

We've u= pgraded Ryan's development server, and the Sandbox server, to OpenSuse = 42.2 (the latest, as mentioned previously) which includes
Mailman 2.1.22.

I'm going to do "ietfc" (= the "unofficial second" hot backup machine) this weekend.=C2=A0 R= yan and Matt will have that machine starting Monday to test and check.=C2= =A0 I hope to hear a good report from them soon (within the week) and do &q= uot;ietfb" (the Orlando/main hot backup) the following weekend, with t= he same subsequent test and check by them.

If all goes we= ll, I will report back to the TMC with a summary of our experiences, and an= assumption of readiness, so that we can schedule the production machine.= =C2=A0 I am guessing, if all goes well, we can do that update live and in p= lace on Monday the 20th, or Monday the 27th, depending on how everything el= se goes.

I hope this answers everything.=C2=A0 Thanks to = you and Ben and everyone for your support!

Best regards,<= br>
Glen

--001a113ce602e70c4a0547a7f919-- From nobody Mon Feb 6 11:25:13 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64721294C7 for ; Mon, 6 Feb 2017 11:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=ge8O0oYZ; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=b9g7SFWg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhC8JDtouLeX for ; Mon, 6 Feb 2017 11:25:08 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7875E1295C5 for ; Mon, 6 Feb 2017 11:25:08 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C6F56209EF; Mon, 6 Feb 2017 14:25:07 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 06 Feb 2017 14:25:07 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=te+mSuc1/hZdDtJrRBiJFavkuc Q=; b=ge8O0oYZwZkgOQmuW+f2q0g4wAA9EUJffTiJhiwgVMkU3Uqt4DSaYRAMxN bOSEk8W3QEq/AHnHz5aOIvV7fPR7tP+lH7SnipJ/rhudwBCER77oeJscfZS9lcXB hJfBWhQnIv1lH6BRs5QqhnVk2czb/jQm+mrEeI2YZuaUiItt4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=te +mSuc1/hZdDtJrRBiJFavkucQ=; b=b9g7SFWgTTs88VSNn2uQhk+CxUIlp5wzz5 KNdBfvsurE4XmKJjwogoZ8ZYN3ygj3RxWojBgDVPt8caD1ja9S16dnmit95WkNKt HIijf8cbmNlux+afkrFixW8aQfsdpCaMsbrT+Ypq5gwbAUvu2rrEEl7uKt4GTklO e5WADcMlE= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A27D06ABF9; Mon, 6 Feb 2017 14:25:07 -0500 (EST) Message-Id: <1486409107.2449104.872189832.69D982D2@webmail.messagingengine.com> From: Alexey Melnikov To: Robert Sparks , Ben Campbell , Glen MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_148640910724491040" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4a450d19 References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <8CB242E9-45B6-43DA-B893-232BC55EE6F5@nostrum.com> <3B7FD5CE-5C9C-4BF4-A352-15F04961F3D2@nostrum.com> Date: Mon, 06 Feb 2017 19:25:07 +0000 In-Reply-To: Archived-At: Cc: IETF Tools Development , Henrik Levkowetz Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 19:25:11 -0000 This is a multi-part message in MIME format. --_----------=_148640910724491040 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi, On Fri, Feb 3, 2017, at 10:02 PM, Robert Sparks wrote: > Alexey should weigh in with more detail, but the essence is that > (extensive) community discussion has already shown that the rewriting > functionality that is in mailman is not sufficient on its own. It > results in (at least) a corruption of recipient's address books that > the community will not accept. The additional rewriting code and the > maintenance of the aliases proposed is what is being proposed to solve > that problem. For the "From rewriting" workaround, we will need alias maintenance scripts. For "message wrapping" we would (ideally) need to modify 1 Python file in Mailman to change the list of header fields preserved in the outer message. (The changes to Mailman are small and we can try submitting them back to Mailman.) > Alexey - could you point Glen to a summary of the discussions that > show _why_ we can't simply use mailman as distributed, and point out > the other consequences I'm sure I've elided? I can dig out more details. > RjS > > On 2/3/17 3:51 PM, Ben Campbell wrote: >> I'm sensitive to the concern about forking MailMan from the distro >> version. Am I correct to assume the existing From: rewriting >> capability is the limited version that Henrik mentioned? That is, are >> we agreed that code changes are required for the plan that Alexey >> described? (Not to question Henrik--I just want to make sure we are >> all on the same page.) >> Thanks! >> Ben (As IESG tools liaison). >> On 3 Feb 2017, at 12:48, Glen wrote: >>> On Fri, Feb 3, 2017 at 8:09 AM, Ben Campbell >>> wrote: >>> > Glen: Are you comfortable with the plan being discussed? >>> > Thanks! >>> > Ben. >>> >>> Hi Ben - >>> >>> >>> Thank you very much for thinking of me. I shall try to be brief. >>> >>> >>> It seems to me that Mailman, right now (as of 2.1.16 - and we are >>> running 2.1.17), has two very valid and useful options for handling >>> DMARC.... (1) From address rewriting and (2) Message >>> encapsulation. By providing these options, it seems to me that >>> Mailman has solved enough of the problems surrounding DMARC to >>> ensure that our list messages can be effectively delivered to >>> everyone on our lists, without tripping over DMARC anymore. Mailman >>> has also, self-referentially, made this the "standard behavior" for >>> Mailman - because of the way they did it, they've set their own >>> standard for DMARC handling, and so this is the way "most people >>> will expect" Mailman to work. >>> >>> So, I would suggest that testing those existing options right now >>> could be done without any effort on my part, or the Tools Team's >>> part, or any disruption. Just pick a list and try it out. >>> >>> In contrast, I am gathering that the plan being considered is much >>> more complex, involving scripting, program changes to Mailman, the >>> creation and management of an additional alias database driven by >>> Mailman, and so forth. I cannot speak to the benefits of this path, >>> but with respect to my comfort, this worries me a bit, for several >>> reasons. >>> >>> My first concern is security. Earlier statements were correct: >>> Mailman upgrades on the IETF servers do happen as a part of OS >>> upgrades, and also smaller updates. OpenSuse, as most distros do, >>> pushes major upgrades and minor updates to their users, which are >>> installed automatically as they are released. This brings with it >>> advantages - new features (such as the already-available DMARC >>> header rewriting options) are pushed to us regularly, and security >>> holes are closed pretty quickly by midstream updates. Although the >>> frequency of these updates is low, it is non-zero, and not something >>> I can discount. >>> >>> By going down this path, the IETF is essentially choosing to fork >>> Mailman, and make something new. In order to even preserve the >>> changes that were made, I'll have to remove Mailman from the server >>> repository catalogs, and relocate the system to a different >>> directory structure to avoid accidental overwrites in the future. >>> By severing Mailman in this way, we will no longer receive updates, >>> and upgrades will have to be done, in essence, manually. This means >>> that someone will have to start "watching" Mailman for upgrades, >>> and, at each upgrade step, the Tools Team will have to figure out >>> how their modifications mesh with the Mailman modifications, reapply >>> their patches and changes (possibly with modifications to the >>> patches), test, and then figure some way to deploy. >>> >>> Since my responsibility is operations, the only way this could >>> effectively work for me would be to turn Mailman into something >>> similar to the Datatracker: The modified Mailman should probably be >>> stored in the Tools SVN server, patches written by the Tools Team, >>> tested and approved by the TMC, and deployed to us as SNV checkouts >>> by Henrik. Then, whenever, changes come out, the Tools Team >>> (re)writes the patches, the TMC tests, and I (re)deploy - just as we >>> do with the Datatracker. (And, if there are issues, as there >>> sometimes might be, I can "roll back" to the previous SVN release >>> quickly and cleanly.) >>> >>> If (and, likely, only if) this is what is being considered, then, >>> yes, I am comfortable. The prep and engineering work would be done >>> by the Tools Team, validation by TMC, and deployment by the >>> Secretariat, just as we do with the Datatracker now. I would be >>> fine with that. >>> >>> But if something different is being considered, then I could not >>> assert comfort without knowing more about the intention. For >>> example, if the intent is to just "have someone do the scripting" >>> and then "send me some zips to install and test", without any >>> validation or vetting.... or if the intent would be to have someone >>> modify Mailman in place because "the changes are small" (or >>> whatever), then, no, my response would have to be that I am horribly >>> uncomfortable with that, because, at the end of the day, if we bring >>> in some volunteer (or contractor) do "just hand us something", then >>> anything that goes wrong whilst the system is live, and/or any >>> debugging that may need to happen down the road would fall on me... >>> and potentially bury me. >>> >>> Under those circumstances, I would not be comfortable at all. So, >>> knowing more about the "operations" and deployment intent here would >>> be most helpful. >>> >>> Too long? Didn't read? >>> >>> 1. Why not try what Mailman already offers, first? It's not IETF- >>> perfection, but it might be close enough to satisfy. >>> >>> 2. If not, then please plan carefully, and do this right: Set up a >>> forked Mailman source tree (and you might as well go all the way >>> to 2.1.23, the latest), apply your patches and changes to that, >>> test it thoroughly offline, make it perfect, check it in, and >>> then give me a Datatracker-style SVN checkout that I can >>> structure on the server without risk to any of us. >>> >>> Under either of those two conditions, yes, I would be comfortable. >>> Otherwise, I'd think not. >>> >>> Apologies if I'm confused or off-point (it happens often!), and >>> thank you again for asking me. >>> >>> Glen >>> >>> >>> >>> >> >> >> _______________________________________________ TOOLS-DEVELOPMENT >> mailing list TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> --_----------=_148640910724491040 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi,


On Fri, Feb 3, 2017, at 10:02 PM, Robert Sparks wrote:

Alexey should weigh in with more detail, but the essence is that (extensive) community discussion has already shown that the rewriting functionality that is in mailman is not sufficient on its own. It results in (at least) a corruption of recipient's address books that the community will not accept. The additional rewriting code and the maintenance of the aliases proposed is what is being proposed to solve that problem.

For the "From rewriting" workaround, we will need alias maintenance scripts. For "message wrapping" we would (ideally) need to modify 1 Python file in Mailman to change the list of header fields preserved in the outer message. (The changes to Mailman are small and we can try submitting them back to Mailman.)

Alexey - could you point Glen to a summary of the discussions that show _why_ we can't simply use mailman as distributed, and point out the other consequences I'm sure I've elided?

I can dig out more details.

RjS


On 2/3/17 3:51 PM, Ben Campbell wrote:

I'm sensitive to the concern about forking MailMan from the distro version. Am I correct to assume the existing From: rewriting capability is the limited version that Henrik mentioned? That is, are we agreed that code changes are required for the plan that Alexey described? (Not to question Henrik--I just want to make sure we are all on the same page.)

Thanks!

Ben (As IESG tools liaison).

On 3 Feb 2017, at 12:48, Glen wrote:

On Fri, Feb 3, 2017 at 8:09 AM, Ben Campbell <ben@nostrum.com> wrote:
> Glen: Are you comfortable with the plan being discussed?
> Thanks!
> Ben.

Hi Ben -


Thank you very much for thinking of me.  I shall try to be brief.


It seems to me that Mailman, right now (as of 2.1.16 - and we are running 2.1.17), has two very valid and useful options for handling DMARC....   (1)  From address rewriting and (2) Message encapsulation.    By providing these options, it seems to me that Mailman has solved enough of the problems surrounding DMARC to ensure that our list messages can be effectively delivered to everyone on our lists, without tripping over DMARC anymore.  Mailman has also, self-referentially, made this the "standard behavior" for Mailman - because of the way they did it, they've set their own standard for DMARC handling, and so this is the way "most people will expect" Mailman to work.

So, I would suggest that testing those existing options right now could be done without any effort on my part, or the Tools Team's part, or any disruption.  Just pick a list and try it out.

In contrast, I am gathering that the plan being considered is much more complex, involving scripting, program changes to Mailman, the creation and management of an additional alias database driven by Mailman, and so forth.  I cannot speak to the benefits of this path, but with respect to my comfort, this worries me a bit, for several reasons.

My first concern is security.  Earlier statements were correct:  Mailman upgrades on the IETF servers do happen as a part of OS upgrades, and also smaller updates.  OpenSuse, as most distros do, pushes major upgrades and minor updates to their users, which are installed automatically as they are released.  This brings with it advantages - new features (such as the already-available DMARC header rewriting options) are pushed to us regularly, and security holes are closed pretty quickly by midstream updates.  Although the frequency of these updates is low, it is non-zero, and not something I can discount.

By going down this path, the IETF is essentially choosing to fork Mailman, and make something new.  In order to even preserve the changes that were made, I'll have to remove Mailman from the server repository catalogs, and relocate the system to a different directory structure to avoid accidental overwrites in the future.  By severing Mailman in this way, we will no longer receive updates, and upgrades will have to be done, in essence, manually.  This means that someone will have to start "watching" Mailman for upgrades, and, at each upgrade step, the Tools Team will have to figure out how their modifications mesh with the Mailman modifications, reapply their patches and changes (possibly with modifications to the patches), test, and then figure some way to deploy.

Since my responsibility is operations, the only way this could effectively work for me would be to turn Mailman into something similar to the Datatracker:  The modified Mailman should probably be stored in the Tools SVN server, patches written by the Tools Team, tested and approved by the TMC, and deployed to us as SNV checkouts by Henrik.  Then, whenever, changes come out, the Tools Team (re)writes the patches, the TMC tests, and I (re)deploy - just as we do with the Datatracker.  (And, if there are issues, as there sometimes might be, I can "roll back" to the previous SVN release quickly and cleanly.)

If (and, likely, only if) this is what is being considered, then, yes, I am comfortable.  The prep and engineering work would be done by the Tools Team, validation by TMC, and deployment by the Secretariat, just as we do with the Datatracker now.  I would be fine with that.

But if something different is being considered, then I could not assert comfort without knowing more about the intention.  For example, if the intent is to just "have someone do the scripting" and then "send me some zips to install and test", without any validation or vetting.... or if the intent would be to have someone modify  Mailman in place because "the changes are small" (or whatever), then, no, my response would have to be that I am horribly uncomfortable with that, because, at the end of the day, if we bring in some volunteer (or contractor) do "just hand us something", then anything that goes wrong whilst the system is live, and/or any debugging that may need to happen down the road would fall on me... and potentially bury me.

Under those circumstances, I would not be comfortable at all.  So, knowing more about the "operations" and deployment intent here would be most helpful.

Too long?  Didn't read?

1. Why not try what Mailman already offers, first?  It's not IETF-perfection, but it might be close enough to satisfy.

2. If not, then please plan carefully, and do this right:  Set up a forked Mailman source tree (and you might as well go all the way to 2.1.23, the latest), apply your patches and changes to that, test it thoroughly offline, make it perfect, check it in, and then give me a Datatracker-style SVN checkout that I can structure on the server without risk to any of us.

Under either of those two conditions, yes, I would be comfortable.  Otherwise, I'd think not.

Apologies if I'm confused or off-point (it happens often!), and thank you again for asking me.

Glen






_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development

--_----------=_148640910724491040-- From nobody Mon Feb 6 11:27:48 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCA41294C7 for ; Mon, 6 Feb 2017 11:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=VgwvauLD; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=HeMCnfQE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZWd2fu1UMoK for ; Mon, 6 Feb 2017 11:27:44 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0761294BA for ; Mon, 6 Feb 2017 11:27:44 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id EE380208C2; Mon, 6 Feb 2017 14:27:43 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 06 Feb 2017 14:27:43 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=xkRcgPQJsHKMxNiCNi6grMEuKk 4=; b=VgwvauLDIFTooPIwqdym3VxYA6E1jh1hdUlqc7Pz4W87CR+gan99H/fuLZ Edc7igYiz6/WOZZwzK09UAv1jAc5A8LAZeEhFFCP+utM8Vo41fbrB77WpmLGrVOB GBV/0OzG/T7VlicSym7ZVHl3wgEq2pNnBU+gGAlSauxB5USjg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=xk RcgPQJsHKMxNiCNi6grMEuKk4=; b=HeMCnfQEUh5ZQP3Ja3D63P8OKFC6lVhMZm OqNL5PlW18DuDMN3skEKcuNG9ntvpKssQKrOP7G5O8RIHtPHpEkgDNUVaeOmUXng 8OiAUpUb/r2971X8LF+P7EcC2wtBcCBB3drveigDDtG86Os51o5gIyTmBziHzLk5 GG7yd2gss= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D03C46ABF9; Mon, 6 Feb 2017 14:27:43 -0500 (EST) Message-Id: <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> From: Alexey Melnikov To: Henrik Levkowetz , Ben Campbell MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4a450d19 In-Reply-To: <5894C795.7020608@levkowetz.com> References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> Date: Mon, 06 Feb 2017 19:27:43 +0000 Archived-At: Cc: tools-development@ietf.org, Glen Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 19:27:46 -0000 Hi Henrik, On Fri, Feb 3, 2017, at 06:10 PM, Henrik Levkowetz wrote: > Hi Ben, > > Strawman for next steps: > > 1. Code snippets from John Levine (via Alexey) > 2. Figuring out where in the mail pipeline the rewriting should happen > (Glen+Alexey+Robert+Henrik, I think) > 3. Figuring out needed glue to use John's snippets (Glen, Henrik) > 4. Installation of OpenSUSE 42.x (Glen, Matt) > 5. Installation of glue code + snippets in conjunction with community > notification about the experiment (Glen, Henrik) Would you like to decide on some dates for the above and maybe we need to have some conference calls to discuss finer details? Thank you, Alexey > Best regards, > > Henrik > > On 2017-02-03 17:02, Ben Campbell wrote: > > (- IESG list ) > > > > Hi Henrick, > > > > What's the next step(s) here? Are we waiting for the MailMan update to > > do further investigation, or can some of the uncertainties be answered > > in the interim? > > > > Thanks! > > > > Ben. > > > > On 24 Jan 2017, at 13:22, Alexey Melnikov wrote: > > > >> Hi Henrik, > >> > >>> On 23 Jan 2017, at 16:54, Henrik Levkowetz > >>> wrote: > >>> > >>> Hi Alexey, > >>> > >>>> On 2017-01-23 12:57, Alexey Melnikov wrote: > >>>> Dear tools team, > >>>> > >>>> The IESG continues to be concerned about the impacts of growing > >>>> usage of > >>>> DMARC technology on IETF discussion lists. All choices in front of > >>>> us, > >>>> including not taking any action, cause some pain, as we have not > >>>> been > >>>> able to identify a perfect approach to mitigate the impacts. > >>>> > >>>> The situation is evolving, as email software evolves and new > >>>> features > >>>> relating to DMARC also continue to be developed. The IESG believes > >>>> that > >>>> we need to be aware of the effects and consider different mitigation > >>>> approaches. The effects are not necessarily easy to predict based on > >>>> theoretical analysis, given the wide variety of software and > >>>> configurations that our participants use, and their personal > >>>> preferences > >>>> among important IETF mailing list functions and avoidance of various > >>>> failure modes. > >>>> > >>>> Robert told us that Mailman is due for an upgrade in February. This > >>>> upgrade would allow IETF to run different IETF mailing lists in > >>>> different configurations. > >>> > >>> I guess this is coupled with upgrading to OpenSUSE 42.x and gives us > >>> Mailman 2.1.18 (or higher) with the DMARC handling options described > >>> here: , yes? > >> > >> I believe so. > >> > >>> https://wiki.list.org/DEV/DMARC > >>> > >>>> The IESG would > >>>> like to perform limited tests on selected lists to determine the > >>>> impacts > >>>> of a couple of different possible mitigation configurations. It is > >>>> important that such an experiment be carefully monitored and that > >>>> the > >>>> impacted users be asked about their experiences. There are strong > >>>> opinions on this matter, but the discussion of this matter has so > >>>> far > >>>> involved a small subset of vocal IETFers. What matters more though > >>>> is > >>>> the experience of the users as a whole. > >>>> > >>>> The two options that IESG would like to test are: From header field > >>>> rewriting (user@example.com would become an IETF managed forwarding > >>>> alias, > >>>> the exact structure is TBD(*)) and message wrapping (encapsulation > >>>> of > >>>> original message inside multipart/mixed, with the original message > >>>> as > >>>> message/rfc822 attachment + some explanatory text). > >>>> These workarounds would only apply to email messages from domains > >>>> that > >>>> publish DMARC p=reject or p=quarantine policy. Messages from domains > >>>> that don't publish DMARC policy or have DMARC policy p=none are not > >>>> affected by this change. > >>>> > >>>> In order to figure out which option has less impact on IETF > >>>> participants, IESG would like to try one of them for a couple of > >>>> weeks > >>>> (+ collect feedback), roll back the configuration to the current > >>>> one, > >>>> then try the other one (+collect feedback) for a couple of weeks. > >>>> Each experiment will run on one or more IETF mailing list. > >>>> > >>>> In order to achieve this, the IESG would like to do the following: > >>>> > >>>> 0) Publish detailed description of how two workarounds are going to > >>>> work > >>>> and comparison of their side effects (both positive and negative). > >>>> > >>>> 1) Decide with the tools team which mailing lists to use for testing > >>>> of each option. This will also need to be agreed with > >>>> managers/working > >>>> group chairs > >>>> of the affected mailing lists. > >>>> > >>>> 2) Discuss with the tools team what kind of changes (new scripts, > >>>> reconfiguration, Mailman options) are needed to deploy both of > >>>> these. > >>>> Agree on when they can be implemented. Publish the timeline to the > >>>> wider > >>>> IETF community. > >>> > >>> If the features of Mailman 2.1.18 are insufficient, the start-up time > >>> (writing new scripts) will be longer than otherwise. This should > >>> maybe > >>> be factored into any decision on exactly which options to try out. > >> > >> Right. From address rewriting will need some scripting work. John > >> Levine said that he could help (he done a version in Python for his > >> mailing list manager, which is not Mailman). > >> > >>> FWIW, based on what I can read out of the available mailman 2.1 > >>> documentation (http://www.list.org/mailman-admin.txt) the From: > >>> header > >>> field rewriting considered above isn't supported by mailman directly; > >>> only replacement of the From: header value with the list address (for > >>> p=reject or p=quarantine domains) and placement of the original From: > >>> address in Reply-To:. So it looks as if the rewrite test option > >>> _will_ > >>> require both new coding and consideration of where in the email > >>> pipeline > >>> the rewrite (and rewrite reversal) should be done. > >> > >> Right. > >> > >>>> 3) Design with the tools team a detailed plan of what kind of > >>>> feedback > >>>> we will be looking for when evaluating results of experimental > >>>> deployment > >>>> of each of these options. Notify the IETF community. > >>>> > >>>> 4) It might be worth publishing a Wiki page describing how different > >>>> email clients, email systems can be used or configured to minimize > >>>> impact of workarounds. > >>>> > >>>> Does this look like a reasonable starting plan? > >>> > >>> Assuming that we can use mailman 2.1.18 features to do the rewriting/ > >>> wrapping, then yes, as far as I can see. If new code is required, > >>> it's > >>> still reasonable if the time and resources issue is considered. > >>> > >>> One more comment below: > >>> > >>>> > >>>> Best Regards, > >>>> Alexey, on behalf of IESG > >>>> > >>>> > >>>> (*) For example, user@example.com would become user@dmarc.ietf.org > >>>> and > >>>> any email sent to user@dmarc.ietf.org would be forwarded to > >>>> user@example.com. > >>>> We are still discussing with Email experts how forwarding emails > >>>> might > >>>> look > >>>> like. Some possibilites are u=user.example.com@dmarc.ietf.org, > >>>> user@example.com.dmarc.ietf.org. > >>> > >>> I'm sure the experts will provide a good suggestion. I just note > >>> that of > >>> the options above, the 'u=user.example.com@dmarc.ietf.org' variant > >>> will > >>> not be able to handle addresses like some.user.name@some.domain.name > >>> (multiple dots in either localpart or domain -- which dot corresponds > >>> to > >>> the at sign when you reverse the address??) well if you expect to do > >>> the > >>> reversal without using saved state. > >> > >> Right, this was just from the top of head. I don't think we want to > >> maintain any state for this. Some kind of encoding scheme would be > >> needed. Possibly replacing @ with %. > >> > >> > >> Best Regards, > >> Alexey > > > > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) From nobody Tue Feb 7 04:52:27 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8889129BA4 for ; Tue, 7 Feb 2017 04:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKypZLU5_Mmk for ; Tue, 7 Feb 2017 04:52:24 -0800 (PST) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE96129536 for ; Tue, 7 Feb 2017 04:52:24 -0800 (PST) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:63880 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cb5Ft-0007yb-GW; Tue, 07 Feb 2017 04:52:22 -0800 To: Alexey Melnikov , Ben Campbell References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> From: Henrik Levkowetz Message-ID: <5899C2F6.50706@levkowetz.com> Date: Tue, 7 Feb 2017 13:52:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7n5s6dPUEccn90pmv1tBhoUUw6FgsXSo7" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: glen@amsl.com, tools-development@ietf.org, ben@nostrum.com, aamelnikov@fastmail.fm X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Cc: tools-development@ietf.org, Glen Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 12:52:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7n5s6dPUEccn90pmv1tBhoUUw6FgsXSo7 Content-Type: multipart/mixed; boundary="rMlvaSfSlgpC3kc5QuwAuEb8TQs8RRALC"; protected-headers="v1" From: Henrik Levkowetz To: Alexey Melnikov , Ben Campbell Cc: tools-development@ietf.org, Glen Message-ID: <5899C2F6.50706@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> In-Reply-To: <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> --rMlvaSfSlgpC3kc5QuwAuEb8TQs8RRALC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alexey, On 2017-02-06 20:27, Alexey Melnikov wrote: > Hi Henrik, >=20 > On Fri, Feb 3, 2017, at 06:10 PM, Henrik Levkowetz wrote: >> Hi Ben, >>=20 >> Strawman for next steps: >>=20 >> 1. Code snippets from John Levine (via Alexey) >> 2. Figuring out where in the mail pipeline the rewriting should happen= >> (Glen+Alexey+Robert+Henrik, I think) >> 3. Figuring out needed glue to use John's snippets (Glen, Henrik) >> 4. Installation of OpenSUSE 42.x (Glen, Matt) >> 5. Installation of glue code + snippets in conjunction with community >> notification about the experiment (Glen, Henrik) >=20 > Would you like to decide on some dates for the above and maybe we need > to have some conference calls to discuss finer details? I just sent out a poll for a conference call to discuss item 2 above. I assume you'll nudge John re. 1, and forward the code when available. Ite= m 3 should follow. 4 is up to Glen and Matt; I think they already sent a tentative timeline. 5 will depend on the rest, of course. Best regards, Henrik >=20 > Thank you, > Alexey >=20 >> Best regards, >>=20 >> Henrik >>=20 >> On 2017-02-03 17:02, Ben Campbell wrote: >> > (- IESG list ) >> >=20 >> > Hi Henrick, >> >=20 >> > What's the next step(s) here? Are we waiting for the MailMan update = to=20 >> > do further investigation, or can some of the uncertainties be answer= ed=20 >> > in the interim? >> >=20 >> > Thanks! >> >=20 >> > Ben. >> >=20 >> > On 24 Jan 2017, at 13:22, Alexey Melnikov wrote: >> >=20 >> >> Hi Henrik, >> >> >> >>> On 23 Jan 2017, at 16:54, Henrik Levkowetz = >> >>> wrote: >> >>> >> >>> Hi Alexey, >> >>> >> >>>> On 2017-01-23 12:57, Alexey Melnikov wrote: >> >>>> Dear tools team, >> >>>> >> >>>> The IESG continues to be concerned about the impacts of growing=20 >> >>>> usage of >> >>>> DMARC technology on IETF discussion lists. All choices in front o= f=20 >> >>>> us, >> >>>> including not taking any action, cause some pain, as we have not = >> >>>> been >> >>>> able to identify a perfect approach to mitigate the impacts. >> >>>> >> >>>> The situation is evolving, as email software evolves and new=20 >> >>>> features >> >>>> relating to DMARC also continue to be developed. The IESG believe= s=20 >> >>>> that >> >>>> we need to be aware of the effects and consider different mitigat= ion >> >>>> approaches. The effects are not necessarily easy to predict based= on >> >>>> theoretical analysis, given the wide variety of software and >> >>>> configurations that our participants use, and their personal=20 >> >>>> preferences >> >>>> among important IETF mailing list functions and avoidance of vari= ous >> >>>> failure modes. >> >>>> >> >>>> Robert told us that Mailman is due for an upgrade in February. Th= is >> >>>> upgrade would allow IETF to run different IETF mailing lists in >> >>>> different configurations. >> >>> >> >>> I guess this is coupled with upgrading to OpenSUSE 42.x and gives = us >> >>> Mailman 2.1.18 (or higher) with the DMARC handling options describ= ed >> >>> here: , yes? >> >> >> >> I believe so. >> >> >> >>> https://wiki.list.org/DEV/DMARC >> >>> >> >>>> The IESG would >> >>>> like to perform limited tests on selected lists to determine the = >> >>>> impacts >> >>>> of a couple of different possible mitigation configurations. It i= s >> >>>> important that such an experiment be carefully monitored and that= =20 >> >>>> the >> >>>> impacted users be asked about their experiences. There are strong= >> >>>> opinions on this matter, but the discussion of this matter has so= =20 >> >>>> far >> >>>> involved a small subset of vocal IETFers. What matters more thoug= h=20 >> >>>> is >> >>>> the experience of the users as a whole. >> >>>> >> >>>> The two options that IESG would like to test are: From header fie= ld >> >>>> rewriting (user@example.com would become an IETF managed forwardi= ng >> >>>> alias, >> >>>> the exact structure is TBD(*)) and message wrapping (encapsulatio= n=20 >> >>>> of >> >>>> original message inside multipart/mixed, with the original messag= e=20 >> >>>> as >> >>>> message/rfc822 attachment + some explanatory text). >> >>>> These workarounds would only apply to email messages from domains= =20 >> >>>> that >> >>>> publish DMARC p=3Dreject or p=3Dquarantine policy. Messages from = domains >> >>>> that don't publish DMARC policy or have DMARC policy p=3Dnone are= not >> >>>> affected by this change. >> >>>> >> >>>> In order to figure out which option has less impact on IETF >> >>>> participants, IESG would like to try one of them for a couple of = >> >>>> weeks >> >>>> (+ collect feedback), roll back the configuration to the current = >> >>>> one, >> >>>> then try the other one (+collect feedback) for a couple of weeks.= >> >>>> Each experiment will run on one or more IETF mailing list. >> >>>> >> >>>> In order to achieve this, the IESG would like to do the following= : >> >>>> >> >>>> 0) Publish detailed description of how two workarounds are going = to=20 >> >>>> work >> >>>> and comparison of their side effects (both positive and negative)= =2E >> >>>> >> >>>> 1) Decide with the tools team which mailing lists to use for test= ing >> >>>> of each option. This will also need to be agreed with=20 >> >>>> managers/working >> >>>> group chairs >> >>>> of the affected mailing lists. >> >>>> >> >>>> 2) Discuss with the tools team what kind of changes (new scripts,= >> >>>> reconfiguration, Mailman options) are needed to deploy both of=20 >> >>>> these. >> >>>> Agree on when they can be implemented. Publish the timeline to th= e=20 >> >>>> wider >> >>>> IETF community. >> >>> >> >>> If the features of Mailman 2.1.18 are insufficient, the start-up t= ime >> >>> (writing new scripts) will be longer than otherwise. This should = >> >>> maybe >> >>> be factored into any decision on exactly which options to try out.= >> >> >> >> Right. From address rewriting will need some scripting work. John=20 >> >> Levine said that he could help (he done a version in Python for his= =20 >> >> mailing list manager, which is not Mailman). >> >> >> >>> FWIW, based on what I can read out of the available mailman 2.1 >> >>> documentation (http://www.list.org/mailman-admin.txt) the From:=20 >> >>> header >> >>> field rewriting considered above isn't supported by mailman direct= ly; >> >>> only replacement of the From: header value with the list address (= for >> >>> p=3Dreject or p=3Dquarantine domains) and placement of the origina= l From: >> >>> address in Reply-To:. So it looks as if the rewrite test option=20 >> >>> _will_ >> >>> require both new coding and consideration of where in the email=20 >> >>> pipeline >> >>> the rewrite (and rewrite reversal) should be done. >> >> >> >> Right. >> >> >> >>>> 3) Design with the tools team a detailed plan of what kind of=20 >> >>>> feedback >> >>>> we will be looking for when evaluating results of experimental >> >>>> deployment >> >>>> of each of these options. Notify the IETF community. >> >>>> >> >>>> 4) It might be worth publishing a Wiki page describing how differ= ent >> >>>> email clients, email systems can be used or configured to minimiz= e >> >>>> impact of workarounds. >> >>>> >> >>>> Does this look like a reasonable starting plan? >> >>> >> >>> Assuming that we can use mailman 2.1.18 features to do the rewriti= ng/ >> >>> wrapping, then yes, as far as I can see. If new code is required,= =20 >> >>> it's >> >>> still reasonable if the time and resources issue is considered. >> >>> >> >>> One more comment below: >> >>> >> >>>> >> >>>> Best Regards, >> >>>> Alexey, on behalf of IESG >> >>>> >> >>>> >> >>>> (*) For example, user@example.com would become user@dmarc.ietf.or= g=20 >> >>>> and >> >>>> any email sent to user@dmarc.ietf.org would be forwarded to >> >>>> user@example.com. >> >>>> We are still discussing with Email experts how forwarding emails = >> >>>> might >> >>>> look >> >>>> like. Some possibilites are u=3Duser.example.com@dmarc.ietf.org, >> >>>> user@example.com.dmarc.ietf.org. >> >>> >> >>> I'm sure the experts will provide a good suggestion. I just note = >> >>> that of >> >>> the options above, the 'u=3Duser.example.com@dmarc.ietf.org' varia= nt=20 >> >>> will >> >>> not be able to handle addresses like some.user.name@some.domain.na= me >> >>> (multiple dots in either localpart or domain -- which dot correspo= nds=20 >> >>> to >> >>> the at sign when you reverse the address??) well if you expect to = do=20 >> >>> the >> >>> reversal without using saved state. >> >> >> >> Right, this was just from the top of head. I don't think we want to= =20 >> >> maintain any state for this. Some kind of encoding scheme would be = >> >> needed. Possibly replacing @ with %. >> >> >> >> >> >> Best Regards, >> >> Alexey >> >=20 >>=20 >> Email had 1 attachment: >> + signature.asc >> 1k (application/pgp-signature) >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --rMlvaSfSlgpC3kc5QuwAuEb8TQs8RRALC-- --7n5s6dPUEccn90pmv1tBhoUUw6FgsXSo7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYmcL8AAoJEE6bV0uPuxca+d8P+wXLReFDT69xOdQ+hh77oD31 GH9Y8Vob0t7Jea7sZxD3ftad0dVmqWd7li9oo8TfFGYe6FWJI1oWiDBIb7suKzRN VMocA8AZWlbMujZK3CPpndDCeXzjm/YdwoGDTJzxR2P+pubBXodwp1UR3ESKkeCt ffjj/IYIagCX8AiDVNy51ldQGR4Uk+Av9yxBoYLoMK2GHifcjSscGlIWX/tXY1Gd FiLOfRcbd5WMCAc+4gYYtevfhCfwq0T/+6448UX9xtG/TjIFhJ8swpLjYMc2K+AV pFuN5Sk70ZLX//u/Ic8z/6i2R4JzI5x8dn5JHZ+WfI4O0N1jb6IzExCnUzQuKF9j 9MjMz5LAmRyJbPFKEbzP9OTIQqKQq5UGQNNL/OQyqL+WDVlIVYSxwW9sQ7BftyBX FFdnMUatCZg645C/00uUt5H/EFX26U+cV7SqV7hqXdvMgrcYUUQlmx86XUWU8J3m c3ox8c/ifUhtxuWXetIEnY9Il+CUn+LDdZ14AMSF1d9yvqX33e++bRn9AR2rN+Oa 66vfVRxVM3RBlHLxqNZOY/E1w/LC3Wq4EhUg2FLBGfRgfDbb7f+jAl5MaUSaZK4Z BF4bAFyoxKseEGuvPN0rDkVjkaHCQdqPHB6r+W09Fj4kkCsK9F0OjNdOClfCISA+ mKTxpY7whvFINWv/ioqm =yBJl -----END PGP SIGNATURE----- --7n5s6dPUEccn90pmv1tBhoUUw6FgsXSo7-- From nobody Tue Feb 7 08:07:49 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F946129CF2 for ; Tue, 7 Feb 2017 08:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6Bok0Mpo3ah for ; Tue, 7 Feb 2017 08:07:47 -0800 (PST) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185DC129CE9 for ; Tue, 7 Feb 2017 08:07:47 -0800 (PST) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:51189 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cb8J0-0003JX-D0; Tue, 07 Feb 2017 08:07:46 -0800 To: Alexey Melnikov , Ben Campbell References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> <5899C2F6.50706@levkowetz.com> From: Henrik Levkowetz Message-ID: <5899F0CA.1030702@levkowetz.com> Date: Tue, 7 Feb 2017 17:07:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5899C2F6.50706@levkowetz.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KFQ8cDBDrUxi5LJt3kBsDl3iB6XSDBwS8" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: glen@amsl.com, tools-development@ietf.org, ben@nostrum.com, aamelnikov@fastmail.fm X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Cc: tools-development@ietf.org, Glen Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:07:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KFQ8cDBDrUxi5LJt3kBsDl3iB6XSDBwS8 Content-Type: multipart/mixed; boundary="nsEplj4kFsrgqdj2NPlLSoeSTRhwgrgc2"; protected-headers="v1" From: Henrik Levkowetz To: Alexey Melnikov , Ben Campbell Cc: tools-development@ietf.org, Glen Message-ID: <5899F0CA.1030702@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> <5899C2F6.50706@levkowetz.com> In-Reply-To: <5899C2F6.50706@levkowetz.com> --nsEplj4kFsrgqdj2NPlLSoeSTRhwgrgc2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alexey, On 2017-02-07 13:52, Henrik Levkowetz wrote: >> > Would you like to decide on some dates for the above and maybe we ne= ed >> > to have some conference calls to discuss finer details? > I just sent out a poll for a conference call to discuss item 2 above. = I > assume you'll nudge John re. 1, and forward the code when available. I= tem > 3 should follow. 4 is up to Glen and Matt; I think they already sent a= > tentative timeline. 5 will depend on the rest, of course. I just closed the poll with this choice (Friday 10th, 20:00 CET, which sh= ould be 11 am PST and 13 am CST: http://doodle.com/poll/vaxnhrvfcvut8myh Alexey, can you arrange for a WebEx meeting at that time, and send invite= s? Best regards, Henrik --nsEplj4kFsrgqdj2NPlLSoeSTRhwgrgc2-- --KFQ8cDBDrUxi5LJt3kBsDl3iB6XSDBwS8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYmfDKAAoJEE6bV0uPuxca7MoP/RzZLx1Ggpdy/j8Po6zOlQn4 Du1TSnV/tg/yI1WLXc2u0N4CYI5NnfsDoDFygmqAFw8V9c5HAxKB+Rf/msXOYEVG vm0f6qaLdtkQIUnkIVRWwWRBukevTkFM7ZEzZR31Mo12QGw64kwlcCoHOwYPlDfM 4kZrr3ecDKT32jGLKQsel9nQ2kN1YRwRnlARYBA7sPzvZKlJ7NZI1/EPu1zgSIRy XSS5iZfbgPV9vUeD/d7XZBRiRVf6DUd4vXMpTrweMiy9wjOEoLu9HuLXwRtAo0Kx yoWt2GY0Kb6F/aiq5qDvB7KF3OULzZkzBxCiZek9R1YRpfRszkjDfbzSZJZjILgH aA7EsObSzMmt4jTUUmH1hiIhnzetixjmNnJ9aPJ5Bi6GC2cCs1GkNoSrmPkhT3Hx SbpmCHWNA1rfVtilId4LYsHE2TLubdmwrKdWmLOz9atZ/zL1nMXA2fnRVAkn7c3G rgJuGUO0UjIqQhQQtUZghJLmvXKkFIt9QFVq67YM0lJsTGoj/UmXwgZzT7fwYWC0 zA97QObIHZGK3TzF2sv0fZ/Wvswe7yvceEwRigi4TIctWxK711WgrClV9ZCjH4ag FkN5QUnXV8hGIF2RPQYTNKTXMZsxY/QgXlyqewvXV6sRRUhJc/0rRIUfvGpwq3Fa tGkJ5dxyg/XCliuhIx+b =F0i1 -----END PGP SIGNATURE----- --KFQ8cDBDrUxi5LJt3kBsDl3iB6XSDBwS8-- From nobody Fri Feb 10 06:54:06 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD7B1299A3 for ; Fri, 10 Feb 2017 06:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=Vd4meiEO; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=aKE4XnGg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z23hHFXEmq7V for ; Fri, 10 Feb 2017 06:54:04 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8BE129987 for ; Fri, 10 Feb 2017 06:54:04 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0BF982085F; Fri, 10 Feb 2017 09:54:04 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 10 Feb 2017 09:54:04 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=DfRIz/5SzHAW1Md2F5nmhUSJNc k=; b=Vd4meiEOYTnD6vcxQ0zii1VA1llsHSVWjH29WtWPyE2I63ZriEn7RVD3yG valKa0Uskw1ZYzw07BxSN46N80X/DvqlsIzumR3QE8lhpoOxPTpzx1BZ5OPsdNcV rOWfHtrGwqIIB8YJ2hmutfjkfcFMDB8+xhx2IPOU8IWRPHc70= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=Df RIz/5SzHAW1Md2F5nmhUSJNck=; b=aKE4XnGgMW10W0h0I85mN9AxCQp933MvbQ VB2Ysm4bu9iAF9boF7cNLE+jBoIvAy3HHAYV4UGFd7aOQpDM90HWz/pulsoUfwnk w3NZzw1WclJy2ZLkGxYc5Jnbeid/2ztNTzNGvq4AFBH26BHPil9FSs20L+4NwUXi gFF8mclEI= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DEC4A6ABF9; Fri, 10 Feb 2017 09:54:03 -0500 (EST) Message-Id: <1486738443.415953.876873848.0CC7B35B@webmail.messagingengine.com> From: Alexey Melnikov To: Henrik Levkowetz , Ben Campbell MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4a450d19 In-Reply-To: <5899F0CA.1030702@levkowetz.com> References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> <5899C2F6.50706@levkowetz.com> <5899F0CA.1030702@levkowetz.com> Date: Fri, 10 Feb 2017 14:54:03 +0000 Archived-At: Cc: tools-development@ietf.org, Glen Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:54:05 -0000 On Tue, Feb 7, 2017, at 04:07 PM, Henrik Levkowetz wrote: > Hi Alexey, > > On 2017-02-07 13:52, Henrik Levkowetz wrote: > >> > Would you like to decide on some dates for the above and maybe we need > >> > to have some conference calls to discuss finer details? > > I just sent out a poll for a conference call to discuss item 2 above. I > > assume you'll nudge John re. 1, and forward the code when available. Item > > 3 should follow. 4 is up to Glen and Matt; I think they already sent a > > tentative timeline. 5 will depend on the rest, of course. > > I just closed the poll with this choice (Friday 10th, 20:00 CET, which > should > be 11 am PST and 13 am CST: http://doodle.com/poll/vaxnhrvfcvut8myh > > Alexey, can you arrange for a WebEx meeting at that time, and send > invites? Sorry, setting the WebEx now. From nobody Fri Feb 10 07:30:39 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B63B1299CD for ; Fri, 10 Feb 2017 07:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUcQDXd3Gl07 for ; Fri, 10 Feb 2017 07:30:36 -0800 (PST) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6371293EB for ; Fri, 10 Feb 2017 07:30:36 -0800 (PST) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:50053 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ccD9f-0000hp-AE; Fri, 10 Feb 2017 07:30:35 -0800 To: Alexey Melnikov , Ben Campbell References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> <5899C2F6.50706@levkowetz.com> <5899F0CA.1030702@levkowetz.com> <1486738443.415953.876873848.0CC7B35B@webmail.messagingengine.com> From: Henrik Levkowetz Message-ID: <589DDC92.7090908@levkowetz.com> Date: Fri, 10 Feb 2017 16:30:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1486738443.415953.876873848.0CC7B35B@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="42TcKhMdQMjBUd2SttvSGgRLNCNoj7O56" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: glen@amsl.com, tools-development@ietf.org, ben@nostrum.com, aamelnikov@fastmail.fm X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Cc: tools-development@ietf.org, Glen Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 15:30:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --42TcKhMdQMjBUd2SttvSGgRLNCNoj7O56 Content-Type: multipart/mixed; boundary="sC2WaKS3WaLstHdNJ5tepG0H4guwEeBir"; protected-headers="v1" From: Henrik Levkowetz To: Alexey Melnikov , Ben Campbell Cc: tools-development@ietf.org, Glen Message-ID: <589DDC92.7090908@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> <5899C2F6.50706@levkowetz.com> <5899F0CA.1030702@levkowetz.com> <1486738443.415953.876873848.0CC7B35B@webmail.messagingengine.com> In-Reply-To: <1486738443.415953.876873848.0CC7B35B@webmail.messagingengine.com> --sC2WaKS3WaLstHdNJ5tepG0H4guwEeBir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-02-10 15:54, Alexey Melnikov wrote: > On Tue, Feb 7, 2017, at 04:07 PM, Henrik Levkowetz wrote: >> Alexey, can you arrange for a WebEx meeting at that time, and send >> invites? >=20 > Sorry, setting the WebEx now. Thank you! Henrik --sC2WaKS3WaLstHdNJ5tepG0H4guwEeBir-- --42TcKhMdQMjBUd2SttvSGgRLNCNoj7O56 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYndyTAAoJEE6bV0uPuxcaRYoP/3Q7JI7Lx2ezErM2ZEK3cehm ODFj8VoRcaUvi4ms9a9rEpF5+FeaD0smlI02tFbkKR1pg027zzmD872vDGDjismH wb7GRRU7V+NC6clx+2wfOnFnepp0jG3fdsYXTWqFyW7xc8mVbV8Hvm7QgHjAeh45 42Ap8MFgHOiCgSFEmFPQrArfukoY8Mgo+JfBkFddV03EAWpfnu6sWktlDZCjvapb EZ+i7ecd9WdYYcTQQEwU8Ak4hvbzVtUcdoDbTErXPIYgIzadqnxpkU7zj2Y1CDJs VHb/JhabQQJOVf3Jx9UId1jw0N3Xnpg/L32OyrM/XUJW1CtyMNFTWmPmBHI5/t3Y BM9ZLRgI40OYqImRMcmnv2B3oOw0vk1oEStczlmalG2hLDHNJU6SfCsH8VZhEgj2 Kj2jKoXChw0r/WjH54HY3NsqMPGSN8GMQOu2pPb+Rc481+Z9eW04xUDsIHQgrzcG 2wGvpzSSVTEqHsB9ksq5yR9kYS4aH9MF1stLF/EtHvR2GrfKqiNGRoGECSuB7qIo 0EZVJQD2jVt3Ia5CcthGTeJYlvfAQiHK4TnJpVpT+RmwmkDihOni61CmiJOxn1x7 oiMFn8/kUrQ5alSK/yvfnCUwU3UwlE20VQqw2lLJiCIxJHeuJ3H0Q2+l0UDipEQs WHjdusfvGdos4JcFpG9v =jUm3 -----END PGP SIGNATURE----- --42TcKhMdQMjBUd2SttvSGgRLNCNoj7O56-- From nobody Fri Feb 10 10:09:58 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C41129A15 for ; Fri, 10 Feb 2017 10:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.702 X-Spam-Level: X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZtvUp48P1-a for ; Fri, 10 Feb 2017 10:09:49 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390461279EB for ; Fri, 10 Feb 2017 10:09:49 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 474701E566F for ; Fri, 10 Feb 2017 10:09:25 -0800 (PST) Received: from mail-ot0-f171.google.com (mail-ot0-f171.google.com [74.125.82.171]) by c8a.amsl.com (Postfix) with ESMTPSA id 248B21E5671 for ; Fri, 10 Feb 2017 10:09:25 -0800 (PST) Received: by mail-ot0-f171.google.com with SMTP id 73so34210311otj.0 for ; Fri, 10 Feb 2017 10:09:49 -0800 (PST) X-Gm-Message-State: AMke39krQzqH7K4XX5cI399p/QOWu1jSi33/rT7/XhNw/gmuMO5uk74tte2P2dgS6pSW6qXiRIEuUT4TGhshAg== X-Received: by 10.157.9.69 with SMTP id 63mr6282929otp.152.1486750188478; Fri, 10 Feb 2017 10:09:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.12.85 with HTTP; Fri, 10 Feb 2017 10:09:27 -0800 (PST) In-Reply-To: <589DDC92.7090908@levkowetz.com> References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> <5899C2F6.50706@levkowetz.com> <5899F0CA.1030702@levkowetz.com> <1486738443.415953.876873848.0CC7B35B@webmail.messagingengine.com> <589DDC92.7090908@levkowetz.com> From: Glen Date: Fri, 10 Feb 2017 10:09:27 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Henrik Levkowetz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF Tools Development , Alexey Melnikov Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: glen@amsl.com List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 18:09:57 -0000 Alexey, I would like to ask that we include Matt Larson (also from AMS) in this call, as he is familiar with the mail handling we already perform. I've forwarded the Webex invite to him but if any additional permissions are needed, could those please be set? Thank you so much! Glen On Fri, Feb 10, 2017 at 7:30 AM, Henrik Levkowetz wrote: > > On 2017-02-10 15:54, Alexey Melnikov wrote: >> On Tue, Feb 7, 2017, at 04:07 PM, Henrik Levkowetz wrote: > > >>> Alexey, can you arrange for a WebEx meeting at that time, and send >>> invites? >> >> Sorry, setting the WebEx now. > > Thank you! > > > Henrik > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > From nobody Fri Feb 10 10:19:44 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D8B129A6A for ; Fri, 10 Feb 2017 10:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=NkwxnUlM; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=e2cYqZ5i Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-MqhZ_55Rmt for ; Fri, 10 Feb 2017 10:19:41 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD291293EC for ; Fri, 10 Feb 2017 10:12:51 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D884E20789; Fri, 10 Feb 2017 13:12:50 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 10 Feb 2017 13:12:50 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=+CLxuXzykcBfiCDlw9UzrVyKmD Y=; b=NkwxnUlMbk/Rq0dmIGGs7q6xO+J1wuE4vLG2uRuXE8JNB+Hb5wwtBg6XZ/ EEZ6ho+GVvYOoTaJ9jxafhKxSTXmMa3kWpheY+KQA0F4di8e3FHXgXemBg60B5Et 6/ysPX+LmKI03MkldiBdXHz3J3FDKVvPpkcdGwwGbPsWSUea0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=+C LxuXzykcBfiCDlw9UzrVyKmDY=; b=e2cYqZ5iJDu4Ebbe0VdWvd6yyxsE7hR0ED CyqLPUiNxewRFL1Iqg1PkWQOUmZ4X/bws3spBHf/23fSdGDCR1LnXr1O5QrRa5xv +3Lp8YPSR6pshLJEIhn10A0hjdPLOM0krwPbCP7WIKA2GutGik1E66+ErR4XXAM4 SW4uYmqRQ= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B85226ABFB; Fri, 10 Feb 2017 13:12:50 -0500 (EST) Message-Id: <1486750370.458963.877098344.51C1707B@webmail.messagingengine.com> From: Alexey Melnikov To: Glen , Henrik Levkowetz MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4a450d19 In-Reply-To: References: <1485172657.2382784.856418992.32E67358@webmail.messagingengine.com> <58863545.1080506@levkowetz.com> <310FC3D7-3CBF-4F71-B5E0-3DB874867736@nostrum.com> <5894C795.7020608@levkowetz.com> <1486409263.2449743.872197120.7AD5D13A@webmail.messagingengine.com> <5899C2F6.50706@levkowetz.com> <5899F0CA.1030702@levkowetz.com> <1486738443.415953.876873848.0CC7B35B@webmail.messagingengine.com> <589DDC92.7090908@levkowetz.com> Date: Fri, 10 Feb 2017 18:12:50 +0000 Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 18:19:42 -0000 Hi Glen, On Fri, Feb 10, 2017, at 06:09 PM, Glen wrote: > Alexey, > > I would like to ask that we include Matt Larson (also from AMS) in > this call, as he is familiar with the mail handling we already > perform. No problems! > I've forwarded the Webex invite to him but if any additional > permissions are needed, could those please be set? I think he just uses the link as everybody else. > Thank you so much! > > Glen > > > On Fri, Feb 10, 2017 at 7:30 AM, Henrik Levkowetz > wrote: > > > > On 2017-02-10 15:54, Alexey Melnikov wrote: > >> On Tue, Feb 7, 2017, at 04:07 PM, Henrik Levkowetz wrote: > > > > > >>> Alexey, can you arrange for a WebEx meeting at that time, and send > >>> invites? > >> > >> Sorry, setting the WebEx now. > > > > Thank you! > > > > > > Henrik > > > > > > _______________________________________________ > > TOOLS-DEVELOPMENT mailing list > > TOOLS-DEVELOPMENT@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-development > > From nobody Sun Feb 12 03:58:35 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22F51294F3 for ; Sun, 12 Feb 2017 03:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMv7OK2yFMhe for ; Sun, 12 Feb 2017 03:58:33 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C15127601 for ; Sun, 12 Feb 2017 03:58:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6E0EB30042D for ; Sun, 12 Feb 2017 06:58:32 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Nn07yJyXC7Br for ; Sun, 12 Feb 2017 06:58:30 -0500 (EST) Received: from [172.26.8.24] (unknown [104.129.194.75]) by mail.smeinc.net (Postfix) with ESMTPSA id A511830024D for ; Sun, 12 Feb 2017 06:58:30 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Sun, 12 Feb 2017 06:58:32 -0500 To: IETF Tools Development X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 11:58:34 -0000 Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern 1. Datatracker Projects - Expected Datatracker Releases -- Robert and Henrik -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan - Contracts for Datatracker Enhancements -- Robert -- Author Statistics 2. Community & Other Projects - Improvements to the mail archive application -- Robert and Ryan - IETF Website Makeover -- Greg and Joe 3. RFC Services Projects - Contracts for Improvements to RFC Services -- Heather and Robert -- CSS for the RFCs -- IDnits -- Publication Formatter -- RFClint -- SVGcheck -- Text Submission -- XMLdiff 4. Server Infrastructure - IESG discussions of DMARC -- Robert and Ben -- Mailman upgrade -- Impact on Internet-Draft-specific mail aliases - Migrate toward Django 1.9 and 1.10 -- Henrik - Libraries for HTML of I-Ds -- Henrik 5. Parking Lot - CDN support for HTML and PDF I-Ds -- Henrik - Migrate from MySQL to PostgreSQL -- Henrik - Discontinue MonArch email archives -- Robert - Improve infrastructure for finding and fetching artifacts -- Robert - Author information for very old I-Ds in the datatracker -- Robert - Replace I-Ds in proceedings with links to archive copy? - Performance improvements and transition to Postgres -- Henrik - VM Architecture for Servers -- Robert - Submit an I-D directly from GitHub - Move downref registry , and integrate with IETF LC generation - Add view of recent ballots by telechat to - Allow meetecho to associate recordings with sessions as they become = available - Mailman support for internationalized email addresses -- Requires Mailman 3.1, which is expected in early 2017 - Meeting registration support for internationalized email addresses -- Mailman must be done first; user is added to meeting mail lists 6. AOB =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D TMC will discuss the RFP responses after the tools call. From nobody Sun Feb 12 03:58:50 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEAB129562 for ; Sun, 12 Feb 2017 03:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK8KxT03ve91 for ; Sun, 12 Feb 2017 03:58:47 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7F81294F3 for ; Sun, 12 Feb 2017 03:58:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2F9D930042F for ; Sun, 12 Feb 2017 06:58:47 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WKcoNXeZipUG for ; Sun, 12 Feb 2017 06:58:46 -0500 (EST) Received: from [172.26.8.24] (unknown [104.129.194.75]) by mail.smeinc.net (Postfix) with ESMTPSA id 1C5FC30024D for ; Sun, 12 Feb 2017 06:58:46 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <545E122B-3619-494C-8991-1E40FB13F802@vigilsec.com> Date: Sun, 12 Feb 2017 06:58:48 -0500 To: IETF Tools Development X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 11:58:49 -0000 Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern 1. Datatracker Projects - Expected Datatracker Releases -- Robert and Henrik -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan - Contracts for Datatracker Enhancements -- Robert -- Author Statistics 2. Community & Other Projects - Improvements to the mail archive application -- Robert and Ryan - IETF Website Makeover -- Greg and Joe 3. RFC Services Projects - Contracts for Improvements to RFC Services -- Heather and Robert -- CSS for the RFCs -- IDnits -- Publication Formatter -- RFClint -- SVGcheck -- Text Submission -- XMLdiff 4. Server Infrastructure - IESG discussions of DMARC -- Robert and Ben -- Mailman upgrade -- Impact on Internet-Draft-specific mail aliases - Migrate toward Django 1.9 and 1.10 -- Henrik - Libraries for HTML of I-Ds -- Henrik 5. Parking Lot - CDN support for HTML and PDF I-Ds -- Henrik - Migrate from MySQL to PostgreSQL -- Henrik - Discontinue MonArch email archives -- Robert - Improve infrastructure for finding and fetching artifacts -- Robert - Author information for very old I-Ds in the datatracker -- Robert - Replace I-Ds in proceedings with links to archive copy? - Performance improvements and transition to Postgres -- Henrik - VM Architecture for Servers -- Robert - Submit an I-D directly from GitHub - Move downref registry , and integrate with IETF LC generation - Add view of recent ballots by telechat to - Allow meetecho to associate recordings with sessions as they become = available - Mailman support for internationalized email addresses -- Requires Mailman 3.1, which is expected in early 2017 - Meeting registration support for internationalized email addresses -- Mailman must be done first; user is added to meeting mail lists 6. AOB =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D TMC will discuss the RFP responses after the tools call. From nobody Mon Feb 13 09:07:17 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A274C1296F0 for ; Mon, 13 Feb 2017 09:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKhLxFdRbKSS for ; Mon, 13 Feb 2017 09:07:15 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D4D1296F4 for ; Mon, 13 Feb 2017 09:07:15 -0800 (PST) Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1DH7ENg027751 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 13 Feb 2017 11:07:15 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local To: tools-development@ietf.org References: From: Robert Sparks Message-ID: Date: Mon, 13 Feb 2017 11:07:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:07:16 -0000 Notes inline: On 2/12/17 5:58 AM, Russ Housley wrote: > Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern > > 1. Datatracker Projects > - Expected Datatracker Releases -- Robert and Henrik > -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan Please skim the release notes for 6.40.4 through 6.43.0 at https://datatracker.ietf.org/release/ > - Contracts for Datatracker Enhancements -- Robert > -- Author Statistics Focus for the last week or so here has been on dealing with the "summary by country" aspects of the reports. We've been working on building the correct models and data-entry tools to support that. Hirch indices and simple graphs should come in this week. The project has uncovered (again) that the author extraction results in the datatracker for old drafts and RFCs is pretty rough. Next steps will involve working with the registration data to build out the meeting attendance statistics. > > 2. Community & Other Projects > - Improvements to the mail archive application -- Robert and Ryan > - IETF Website Makeover -- Greg and Joe > > 3. RFC Services Projects > - Contracts for Improvements to RFC Services -- Heather and Robert > -- CSS for the RFCs Essentially done, but being polished. We are getting an updated release this week. The exercise has uncovered several bugs in the HTML example documents (and a few in the HTML format spec) that are being tracked. > -- IDnits > -- Publication Formatter > -- RFClint > -- SVGcheck > -- Text Submission > -- XMLdiff We have had kickoff calls with both of the format developers. I will create a page showing expected roadmap sometime before the next tools call. > > 4. Server Infrastructure > - IESG discussions of DMARC -- Robert and Ben > -- Mailman upgrade > -- Impact on Internet-Draft-specific mail aliases We had a design call with Glen, Matt, Henrik, and Alexey last week. Our next steps are still investigatory. We'll be looking at the code John Levine has been using for managing mapped aliases when rewrites are necessary (pending getting that code from John), and investigating where in or around Mailman to add the rewrite logic that Mailman doesn't already support. We're keeping handling the issue for the draft-* and wgacronym-* aliases in mind, but are not necessarily tackling that at the same time - rather our initial focus will be on messages that go through mailing lists. Henrik - feel free to correct anything I've mischaracterized or add to what I've missed. > - Migrate toward Django 1.9 and 1.10 -- Henrik > - Libraries for HTML of I-Ds -- Henrik > > 5. Parking Lot > - CDN support for HTML and PDF I-Ds -- Henrik > - Migrate from MySQL to PostgreSQL -- Henrik > - Discontinue MonArch email archives -- Robert > - Improve infrastructure for finding and fetching artifacts -- Robert > - Author information for very old I-Ds in the datatracker -- Robert > - Replace I-Ds in proceedings with links to archive copy? > - Performance improvements and transition to Postgres -- Henrik > - VM Architecture for Servers -- Robert > - Submit an I-D directly from GitHub > - Move downref registry , and integrate with IETF LC generation > - Add view of recent ballots by telechat to > - Allow meetecho to associate recordings with sessions as they become available > - Mailman support for internationalized email addresses > -- Requires Mailman 3.1, which is expected in early 2017 > - Meeting registration support for internationalized email addresses > -- Mailman must be done first; user is added to meeting mail lists > > 6. AOB I don't think this needs time on the call, but I wanted to make sure everyone was aware: The review tool is getting a lot of use and we are getting many positive notes of feedback, and quite a few tweak requests - tickets related to the review tool are the majority of what we've received in the last few weeks. See > > == == == == == == == > > TMC will discuss the RFP responses after the tools call. > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Mon Feb 13 09:22:42 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15298126DFB for ; Mon, 13 Feb 2017 09:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wce_dPzvqzhg for ; Mon, 13 Feb 2017 09:22:39 -0800 (PST) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E9B1294C6 for ; Mon, 13 Feb 2017 09:22:39 -0800 (PST) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:55315 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cdKKk-0001AQ-4a; Mon, 13 Feb 2017 09:22:39 -0800 To: Robert Sparks , tools-development@ietf.org References: From: Henrik Levkowetz Message-ID: <58A1EB52.2070300@levkowetz.com> Date: Mon, 13 Feb 2017 18:22:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L23mODnH1aRlu3FmTVdUn3CmWH79D1tAR" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: tools-development@ietf.org, rjsparks@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:22:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L23mODnH1aRlu3FmTVdUn3CmWH79D1tAR Content-Type: multipart/mixed; boundary="4hathbF9Uq6P1BU5QrKblmpkovK85cGxG"; protected-headers="v1" From: Henrik Levkowetz To: Robert Sparks , tools-development@ietf.org Message-ID: <58A1EB52.2070300@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern References: In-Reply-To: --4hathbF9Uq6P1BU5QrKblmpkovK85cGxG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A few additional details from me: On 2017-02-13 18:07, Robert Sparks wrote: > Notes inline: >=20 > On 2/12/17 5:58 AM, Russ Housley wrote: >> Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern >> >> 1. Datatracker Projects >> - Expected Datatracker Releases -- Robert and Henrik >> -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan > Please skim the release notes for 6.40.4 through 6.43.0 at=20 > https://datatracker.ietf.org/release/ >> - Contracts for Datatracker Enhancements -- Robert >> -- Author Statistics >=20 > Focus for the last week or so here has been on dealing with the "summar= y=20 > by country" aspects of the reports. We've been working on building the = > correct models and data-entry tools to support that. Hirch indices and = > simple graphs should come in this week. The project has uncovered=20 > (again) that the author extraction results in the datatracker for old=20 > drafts and RFCs is pretty rough. Next steps will involve working with=20 > the registration data to build out the meeting attendance statistics. >> >> 2. Community & Other Projects >> - Improvements to the mail archive application -- Robert and Ryan >> - IETF Website Makeover -- Greg and Joe >> >> 3. RFC Services Projects >> - Contracts for Improvements to RFC Services -- Heather and Robert= >> -- CSS for the RFCs > Essentially done, but being polished. We are getting an updated release= =20 > this week. The exercise has uncovered several bugs in the HTML example = > documents (and a few in the HTML format spec) that are being tracked. >> -- IDnits >> -- Publication Formatter >> -- RFClint >> -- SVGcheck >> -- Text Submission >> -- XMLdiff > We have had kickoff calls with both of the format developers. I will=20 > create a page showing expected roadmap sometime before the next tools c= all. >> >> 4. Server Infrastructure >> - IESG discussions of DMARC -- Robert and Ben >> -- Mailman upgrade >> -- Impact on Internet-Draft-specific mail aliases > We had a design call with Glen, Matt, Henrik, and Alexey last week. Our= =20 > next steps are still investigatory. We'll be looking at the code John=20 > Levine has been using for managing mapped aliases when rewrites are=20 > necessary (pending getting that code from John), and investigating wher= e=20 > in or around Mailman to add the rewrite logic that Mailman doesn't=20 > already support. We're keeping handling the issue for the draft-* and=20 > wgacronym-* aliases in mind, but are not necessarily tackling that at=20 > the same time - rather our initial focus will be on messages that go=20 > through mailing lists. Henrik - feel free to correct anything I've=20 > mischaracterized or add to what I've missed. Everything seems right and to the point. We have tentative insertion points for both rewrite of outgoing addresses to mangled addresses@x.ietf= =2Eorg and incoming addresses@x.ietf.org to correct final addresses, but will trial run this on sandbox.ietf.org before the first test on live lists. >> - Migrate toward Django 1.9 and 1.10 -- Henrik Django 1.9 done and released, Django 1.10 getting closer, expecting it at the beginning of next week. >> - Libraries for HTML of I-Ds -- Henrik Next after Django 1.0 are 4 smaller schema change tasks; this task of=20 breaking out the htmlization code into a lib and integrating that in the = datatracker (which could be a largish task) is scheduled after those. >> >> 5. Parking Lot >> - CDN support for HTML and PDF I-Ds -- Henrik >> - Migrate from MySQL to PostgreSQL -- Henrik >> - Discontinue MonArch email archives -- Robert >> - Improve infrastructure for finding and fetching artifacts -- Rob= ert >> - Author information for very old I-Ds in the datatracker -- Rober= t >> - Replace I-Ds in proceedings with links to archive copy? >> - Performance improvements and transition to Postgres -- Henrik >> - VM Architecture for Servers -- Robert >> - Submit an I-D directly from GitHub >> - Move downref registry , and integrate with IETF LC generation >> - Add view of recent ballots by telechat to >> - Allow meetecho to associate recordings with sessions as they bec= ome available >> - Mailman support for internationalized email addresses >> -- Requires Mailman 3.1, which is expected in early 2017 >> - Meeting registration support for internationalized email address= es >> -- Mailman must be done first; user is added to meeting mail lis= ts >> >> 6. AOB > I don't think this needs time on the call, but I wanted to make sure=20 > everyone was aware: > The review tool is getting a lot of use and we are getting many positiv= e=20 > notes of feedback, and quite a few tweak requests - tickets related to = > the review tool are the majority of what we've received in the last few= =20 > weeks. See >> >> =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D >> >> TMC will discuss the RFP responses after the tools call. >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --4hathbF9Uq6P1BU5QrKblmpkovK85cGxG-- --L23mODnH1aRlu3FmTVdUn3CmWH79D1tAR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYoetSAAoJEE6bV0uPuxcaldUQAKz+H4y4GtaQqX7yGYslvXKl 5kff4sSHNx2v5W2Y6H/9YW6cdiVbjOYFLlQNtXQaiwzQrmdB0sCkRZSz8ibczRd9 3Co4EgWTrkeyLtVv1JjhswIu2c1n7eCb1Ikf+AXwx0P5c2tbO14+JJphPn7RLfl9 5IIXpv7K8jCClRlgO5R4GIRfU5r4HN5lpAv7p8DpxexaLLOj0X6xgtofgynb8KC6 zH61jnnfIXd9D2OgP+rt+fn1N5LGqWM/Y6+bOB0YO2djnxkHqNoUWa4TKi69Geco 2kVGgSxxkZAGD40UNbCtiU+ckbF3Tgt3TjW3gtMFYGqjmQ0D5roQ7A7/F00sDQ1e F7hI0KmaJ/zV6Es0tb3KQ4VXvW+7OI1Bze6ZzLayA7ewGZB/qsJ9K90cMlJRudNb 0R9OKn7pGXFi+JsmWL0yd1QWtYTkCPUaJJBWClhksXd59pYI62yibCAQG7aOxbSw Sio88HO15+QyN0T3KuyaJc9FyUP6yGOsMjWZmi+DAnDTW3Nhz5mpdwCtNJD8VCOf Q/mM5GHp0mls0Z61x1aaD5m63NjrxRxfQ09VtXvMimJrAttra68e7Jd3TA+lwxFZ Qu876XKYnkaSaVR5Z6qAmZKn0AbJ5FI0KBEG9rFeleUje1xQGPHd2N94FooJwgaH NLxwskfzkvo8jQTn+rJS =Cfxa -----END PGP SIGNATURE----- --L23mODnH1aRlu3FmTVdUn3CmWH79D1tAR-- From nobody Mon Feb 13 10:37:01 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EF01297C1 for ; Mon, 13 Feb 2017 10:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XChoV_SHLLt5 for ; Mon, 13 Feb 2017 10:36:59 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34171294A0 for ; Mon, 13 Feb 2017 10:36:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5C42930042F for ; Mon, 13 Feb 2017 13:36:58 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PbPA-ntez1A2 for ; Mon, 13 Feb 2017 13:36:57 -0500 (EST) Received: from [64.170.98.129] (unknown [64.170.98.129]) by mail.smeinc.net (Postfix) with ESMTPSA id B29A9300293; Mon, 13 Feb 2017 13:36:56 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C61D77E7-7818-4603-9ED7-3DD658E45CC2" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Feb 2017 13:36:55 -0500 In-Reply-To: To: Robert Sparks References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 18:37:00 -0000 --Apple-Mail=_C61D77E7-7818-4603-9ED7-3DD658E45CC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 13, 2017, at 12:07 PM, Robert Sparks = wrote: >=20 >> 1. Datatracker Projects >> - Expected Datatracker Releases -- Robert and Henrik >> -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan = > Please skim the release notes for 6.40.4 through 6.43.0 at = https://datatracker.ietf.org/release/ = >> - Contracts for Datatracker Enhancements -- Robert >> -- Author Statistics >=20 > Focus for the last week or so here has been on dealing with the = "summary by country" aspects of the reports. We've been working on = building the correct models and data-entry tools to support that. Hirch = indices and simple graphs should come in this week. The project has = uncovered (again) that the author extraction results in the datatracker = for old drafts and RFCs is pretty rough. Next steps will involve working = with the registration data to build out the meeting attendance = statistics. RE: Meeting Registration Data I am thinking that as part of the proceedings processing. The summary = information for a particular meeting can get added to the datatracker. Russ --Apple-Mail=_C61D77E7-7818-4603-9ED7-3DD658E45CC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 13, 2017, at 12:07 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

1. Datatracker Projects
   - Expected Datatracker Releases -- Robert = and Henrik
     -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan
Please skim the release = notes for 6.40.4 through 6.43.0 at https://datatracker.ietf.org/release/
   - Contracts for Datatracker Enhancements -- = Robert
     -- Author = Statistics

Focus for the last week or so here has = been on dealing with the "summary by country" aspects of the reports. = We've been working on building the correct models and data-entry tools = to support that. Hirch indices and simple graphs should come in this = week. The project has uncovered (again) that the author extraction = results in the datatracker for old drafts and RFCs is pretty rough. Next = steps will involve working with the registration data to build out the = meeting attendance statistics.

RE: Meeting Registration Data

I am thinking that as = part of the proceedings processing.  The summary information for a = particular meeting can get added to the datatracker.

Russ

= --Apple-Mail=_C61D77E7-7818-4603-9ED7-3DD658E45CC2-- From nobody Tue Feb 14 06:57:12 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7693129503 for ; Tue, 14 Feb 2017 06:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAS4HgDvlbK4 for ; Tue, 14 Feb 2017 06:57:08 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0086.outbound.protection.outlook.com [104.47.38.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D091270B4 for ; Tue, 14 Feb 2017 06:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BnXNVTJnGBqn0dULn0k3D3/zs1SzzeqXvRXaLojJNRg=; b=ss9rCZ66OoNywr1RbajG8iehIilhLepI4fqllDURNxjsDQOSCFrCWeSRZadBigaj09Rc4vHzd+0IqjkavdFRMP/pLUQEf/yzUGixkqmRrQfHX1nygvQBKldhlJivu1XcNN6yj6c152oZudX5+PXxQ0cZ0tX4TcpV6NASH1+jbyc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=wood@isoc.org; Received: from [IPv6:2001:4870:400e:402:98a9:678c:f5ba:9331] (2001:4870:400e:402:98a9:678c:f5ba:9331) by BN6PR06MB2850.namprd06.prod.outlook.com (10.175.127.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 14:57:05 +0000 From: Greg Wood Message-ID: <79CFA618-F315-4160-89EC-6EA780B4C959@isoc.org> Content-Type: multipart/signed; boundary="Apple-Mail=_2FC63002-CCED-4FEF-8C3F-2641F8BA031C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Feb 2017 09:57:02 -0500 In-Reply-To: <545E122B-3619-494C-8991-1E40FB13F802@vigilsec.com> To: Russ Housley References: <545E122B-3619-494C-8991-1E40FB13F802@vigilsec.com> X-Mailer: Apple Mail (2.3259) X-Originating-IP: [2001:4870:400e:402:98a9:678c:f5ba:9331] X-ClientProxiedBy: DM5PR20CA0042.namprd20.prod.outlook.com (10.171.161.156) To BN6PR06MB2850.namprd06.prod.outlook.com (10.175.127.144) X-MS-Office365-Filtering-Correlation-Id: c4eec7ad-4c32-4555-ebf8-08d454e9be27 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2850; X-Microsoft-Exchange-Diagnostics: 1; BN6PR06MB2850; 3:rqSZ2s14SROOpZloNR7tkQM23FQdSLDX/evl5zDSW6nHFiWpq1ftxYdAw+I+PRAGXzAZGyT5tAcg/5KdYhY2MDiqBgvO3AcrzAI/lddBCi6FiQzeDcAK7Q0MkHzPLrZwnedIGNgrLTNxbnG4HR9IHvam7jF+6sIdw8HX11wNLYSEcaubF0eVVSg+eb2mHLd+cuACw+JNMW6ao3fQyTLTgDPuxtwlC2GJV4+JGP3avUbXo/KCTAu0nw9GJQILfXdo/QyQN+AK+55LaaoX8dIcpw==; 25:lcnxo2zJ6eMVpt4V66tKgs+8GKY2Xt/c4R9OUk0pA/VSAxwfozPZ5OrL7yBfNCpYWkQ+Fiaxr2cYo9/Oawg/W91Df4zan8asBGYLrLOYakyyi5w+FDNZ9olaCwXFFEV6MyuI6DEv1t+T9j1H0k5Vu33rxKPxEqQKvezB9xlscHfLR2Hpq+F3JNgZMovmBXguYwk1JoV1BwSxUuCzkM/Osd/bYZLPhLhECWlfM4yx5qucbGtU+1ei9WGrTPYmJVuhlP8LdTlr64b0sgVlpSSjaytFZ13Ikc5B+AAfkpYYPDiL9Vs2EKY3JVpfL5pbwvTdh5EQ/beOuZvxp9mXTmJvBf0XT5AUvO5D1c5p0EmAJuVbpFQ73NtD5kD0fOoXqYnx8EekO3HoIzAiiM082bkd5/k2iLHZb3mOrVu8e37StsYVBlLWqc1IM16K8Wiq3BwyJ5CJMSnfF+cjA1SzMO8vJg== X-LD-Processed: 89f84dfb-7285-4810-bc4d-8b9b5794554f,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; BN6PR06MB2850; 31:pWrpn6RHcNuJZFHxG0b5R5NbWFBF9N/sF61968GnDz4SIPOoB/hqoyXBOOv4+zKYZ9+KFYTPho86BTfXXPv7NAZoP2g/BulDWIpAuEyfmyIbCUMC/hP8qkxh+t0nTIzYpQHRLN/ROTlHX7m+R1buDd6YwoOQDNxqW76WIvNWEdXTQr0JKLfOqG/OyPTZnq1phz4Xe97TyFe5mFUwizh/zKllw2X/Fp6jEIHDFfsUIMMvO6kIWPwxE4MYW33fp+kN4XfWgnjdrIuU0Rr1UcPZ4HbKTJMeaK7OXjr3A8kyPYw=; 20:ZRomffU3efRgt60L9uQIix2UfDPYxauApYGYCi38hQFdZOdBfVrHKqVWmq9b/HdjZJenYUCzY6tT64NnCQJz1fPZKSmstqTxPMm9xOEQCAOfhEPJU1JxnOTWdCLlWItZQRe75ROqaggMr5unzeeoHAzpePMcZXvr70pi0sKSb1cWKcagjZL0p+i5J7/MRd1PfQEWEyU74/voby7/xnkjPiQkiFQyInGtBz+z3IlJPfnlRYOc5EsmsWjDoRfSbs3PU2A+A41upguZ3WoytzjVdfiq3qaeOckN8bIVdtk0soXOSh2raPCeMN/e+wsqGzwG2I6GJ7tvd3GvKiDBnJgZR5kaPZ24DVtL2zkOcHsMAghSvPHwQOlCAVTmdJPiDiF3ViY2mDb5HUCCl77Rda+Kaxj3o9q4kMR/kuHNfx/nzFbSbB/G+UoJGoou+IZQkIlFx75i5oW6lqrSKtQNV0HSvUYlKa2aREMgzcaMnhAIczjOX5zUN+qXkCZaTm4+lKx8 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(788757137089)(5213294742642); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148); SRVR:BN6PR06MB2850; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2850; X-Microsoft-Exchange-Diagnostics: 1; BN6PR06MB2850; 4:Id9TunGcSHJFvLyyfN+hQLumAnK1a7EcoJU7EI5ySyPJDbiU7SbpnhINVA9VXEE96F3vS9JykbEB+3IPUlQUWr1DZg1u4kOH8uSOABjoJqZhI99ZxcaAa5QOxz9f1PjRltk/jNC648JIi9k4lg1uMohkA4MbeEezs+aPzEydSbsX9inSOnAkte0Cj1tteSekv7L/25b3aw8AGUkrsu4B3T4ydBZTidsZdt284MmI6wOpDBuZH70jl6gw/Si6ukE+L6cBuZXmORum+GzSHD0UdtpngUE5ZSseztEd+JmgWoz0qxxRJ9faKwK1lRQ9bwKmDPZxYgCO+IxeYNWXgnS90xrL0I89cU633Sxv2xXsruweEhVOr1DizorRmyvllG+q1cf1D36/AVfHPQJoa1ZZ8Yy+PALacLjb17D1Qrpm/ambln+ZMCzf6EoShXgVBen73sR3c0JUamQM1pGhXUmRkaqJskDrR8QMozOvbaid/k4CK1acGE6byMwpp7unMDyC8ShGoMe8c7c4TVXHGJ3Pw1UA+lrT7RHMYzAR5HXnQmK+jeQjwQ2N1BAtjtxnZokUJS3PT2M3ep3brw9mZQsCLezLtz+Duf8J1L5TDRx38Fpl+IqyjFHhEAvmwPHXtSC6EwWexgtIuGs00tZpiRtZ2pd+5JHjmUTWqD2uyagrNopdEuY4fkW1dKpL/UONnekRgUxE0rIJ0dOyUHbdjs1DWQ== X-Forefront-PRVS: 0218A015FA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7916002)(39450400003)(377454003)(189002)(24454002)(199003)(38730400002)(53936002)(6666003)(512874002)(6306002)(8676002)(86362001)(68736007)(6486002)(81156014)(76176999)(81166006)(2950100002)(82746002)(7906003)(110136004)(92566002)(966004)(84326002)(606005)(229853002)(568964002)(7736002)(1720100001)(36756003)(105586002)(236005)(33656002)(50986999)(6116002)(6246003)(106356001)(83716003)(101416001)(25786008)(189998001)(69556001)(4326007)(1706002)(6916009)(2906002)(57306001)(5890100001)(5660300001)(97736004)(42186005)(50226002)(81003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB2850; H:[IPv6:2001:4870:400e:402:98a9:678c:f5ba:9331]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR06MB2850; 23:+Nz5uSM469oMXMbzOrNdchabuxDrJAWD1NlrLmqw7?= =?us-ascii?Q?VLFMZ2XfalWtOoGkUaKKVlGb5LdSBTdL9twRmqvgxzTF+LqXAO2kwMAc4uUY?= =?us-ascii?Q?q4lYtvQiWkFaiLAeY/mqMVRMYJ95zNycLARXRKyDxviHIqhOja4hxv6yLwxl?= =?us-ascii?Q?wUqZ2MajWVZN150WOtB8NhU3FP8PPqF9lfnHEwh77tbw3wEPf8b/nANK9pTN?= =?us-ascii?Q?4gBE3xXhbyG0B4ur4IJWvliHD2+slL5ySVbPeHZhhE9BoOjXRnPkseQWUrlz?= =?us-ascii?Q?M6hG7WTmvA9Tt7Wgbj9WMuGS/N1RMmtPs2kmG+9lh8h8jk3bFv5Hg1Q5NJ3y?= =?us-ascii?Q?ShxR1MmgzZgBXnD7rHNpYChph+kbzZ59YkrL5hsiuvsKob8Fy2c79+xy1CHW?= =?us-ascii?Q?H7gLFEhil8b0kiJwtbJArglzdTFLqQJMkQYySnxBzOE/TXM7KuFICqt05t8l?= =?us-ascii?Q?pdX8YMty++1LuHLxF3F0s7f4U22v0yJ+mQ58KiBDz3/Ltb/eWqKYL+oW6Ql/?= =?us-ascii?Q?v5ENgJbnzv8j11yZUUTL5Bkj3lMzgCRiXjn2lMACAXVwOkDCemqKSkFmLudv?= =?us-ascii?Q?VoZh2STpyrePae4absQV2HlLbaGyUZAEvEu78XK9+QBW3XQbobQM46/TXD7C?= =?us-ascii?Q?lsFZuh2oJzB28QSrKMtpScC+VkqUEdtK0txqOvBP1Gx14xu9aeVUSNp1N3N4?= =?us-ascii?Q?ogsdXda7xyAWBrIZrjkTLwLhIi5fvgrvTcWOI2BjLbWQAieOJgmQpkHjqCvT?= =?us-ascii?Q?0bVybY5ixxUcgRfyRvRyiL2NCZZNkjUbO/8vmBFunjnuo1tjwjplqtyPPAlQ?= =?us-ascii?Q?jbjkF9O0PJsdxKrR43QpMMPNjEi+VzhcSjuttrxsEtPXSHTtny+mlLG3Nbsr?= =?us-ascii?Q?fMj0pB8YgfXAeU85pf2PA/rB4/QAPY834AcMGh0Ij0KuUx9Z+r83Di0YZOcP?= =?us-ascii?Q?CT6NREnL7Yo/lJYiwy6jcx+ZbiknFNZ5Dpy8ovXLOtcg22amvaNaZvs+hP90?= =?us-ascii?Q?POCxKjz1Sb0Hr5LKCIWN2Fxz7gzfgRLpssemjc0k24qeaMY29rCRKlY4OL8m?= =?us-ascii?Q?oUQO9He23g6KRXwgKJ2QyVFUSEt/CPI9VsGhYkh4RnudrY3x5VNLz4EZLWvj?= =?us-ascii?Q?9tFPv2fdA+mWriC/wyH+lCwECjgqYiP57XWZp33vi965hrvH2XB0OR++00F6?= =?us-ascii?Q?QzTRjPIHDaCWAaQueROFzvN2N8THGl2xFRZBzc8zkCUmbZcBrVJPDHmVdZTx?= =?us-ascii?Q?5/NjWN2ESkGwoVVnBAB0FrI2cQr/VLnLi/Yi3rHzelwvcaGqCae/DNqsHWSR?= =?us-ascii?Q?uFJTPSUTRhK1qQdv0ECc5w=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR06MB2850; 6:BSqHynmmNYO4edEth86zUCT7yZ6mpgG2E7W+eEB2HEtELgD0u0sDB7ggryn1q+I254Gtqc1I+YoqTDMWRVtyXRgsDdBtndyMAQbMPoQ+CzuWgvDxfbAhSkBlPMg0/Cff6DZPpLg9dTLtftgAi3S8C110z9XBiv5tOfb2AyetzVhVR6LeVMCihnK/SD7ZqzafWRBSxI1u1g0Z/DXVt0up3nxXwRJaw3Ew+gT0XPupR0I88p5/Ok8lC/7mr+t0WjbxHbb5RONb/WO7cCvVTR1f52UOGGw4Tmt1nwikNwfrTda17e5E00inkYI7lc/szrbMhOJPrE6syFR2X4NYXl4pID+9Bg2Q2GP4UE/bv17pvJDFIFxFp5D0LcQMnHn0CLSdFfJ6Whc4ARpUON/h7hcl1A==; 5:pYC8r1lfU5vPGvvltd5ZpmGXV/axnjjVIurLO2HCM/DWVlrfJ6hla7YDLltiM2K+rGCayR4y7TQfd0LZxl75trqAVhGJ2JAqXZNPWm6HqOrUUDIczzwLbaclWvO5PwFdcKKfqJGAGw1fmkDw74uCs7JvM3bjnSJQ07cdaKkrZGU=; 24:VTpUWOYw4I+w4FAUJkl1NJUc7G6zdrYYlKkqswwX/to2yjSYM5wGhw6f+tzRx0z2M+sGaoNX62YJJN3P1u3z+wyRKM8KC9p8YuKEtzwcvSw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN6PR06MB2850; 7:7tQGx1bkf7NAogMx7fJLOn0w4dmlkh/8XyrtIThaRLVdQEHUtnNmE9hJb1Z5GOEBBPgpC9ELigPtLNq1ry/b6Oc6mWVK2AThiAIGS6jlgUawraqqGQnfRr5LaFFXV89Ex8DjUh1jy9c3Whx3f1KwiS0vbDozc75AjOFE9N3ESvT6jPnqZU6KDfoi6ud88VhJ1U5Eet9zEtyehmdXfU6iCUOW1jVzq/zeQbcQLbwEzeNY9Fi0XnylWyV1tJ0fesrOa3LC1SV4dVzuV8gD9aEjBNdH0ZkZq3SDRnyCBklZzbo4+R0gZSZ/AV9+JDy9q7alN1QfZJWzm2aqpSki0I+Ywn/c/0ediSb9zdICWCrZ5zdDGjXmcQZAsfyHTBvCVeN3/bCaB9ahIW/u2qL5+FdbIgPz4GAEBUkYvy6f8gT6J4nS83/P4GarE4VeEpvTNC3bZfoofnnzE3IhbAJVnYwgNdSRYbCrKWz/G8SWB/nHk8oJ/5URwVRsIRVbdeP42oyFlkifpX3vKQILr5qyCS31Dg== X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2017 14:57:05.5478 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2850 Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 14:57:11 -0000 --Apple-Mail=_2FC63002-CCED-4FEF-8C3F-2641F8BA031C Content-Type: multipart/alternative; boundary="Apple-Mail=_0CC202DD-59C4-4B49-AC2E-7D88B26A1D33" --Apple-Mail=_0CC202DD-59C4-4B49-AC2E-7D88B26A1D33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Apologies, I have a conflict with the IETF meeting team call at exactly = the same time so won=E2=80=99t make the call today. An update below. > On Feb 12, 2017, at 6:58 AM, Russ Housley = wrote: >=20 > Tools Call Agenda -- 14 Feb 2017 at 1:00 Eastern >=20 > 1. Datatracker Projects > - Expected Datatracker Releases -- Robert and Henrik > -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan > - Contracts for Datatracker Enhancements -- Robert > -- Author Statistics >=20 > 2. Community & Other Projects > - Improvements to the mail archive application -- Robert and Ryan > - IETF Website Makeover -- Greg and Joe Update on IETF Website revamp project Following a conversation I had with TBX on Thursday, Joe and I discussed = the status of the website revamp on Friday. Issues 1) Fixing front-end bugs: Blocking community review process There are several outstanding bugs with templates (filed on Codebase) = that TBX acknowledge and agree to fix. However, they have had a resource = shortage (sysadmin time to prep for frontender fixing) that is = preventing the fixes from happening. They expect to have a new sysadmin = on board this week and are expecting these fixes to be ready for = deployment by the end of the week (17 Feb).=20 The implication of the delay in getting these resolved from our end is = that the front-end bugs won=E2=80=99t allow proper community review of = the content=E2=80=94that is the presentation will be sufficiently broken = to be distracting from the testing/review we want to undertake. Given = past delays, we are waiting to move forward with scheduling reviews = until these are definitely resolved. 2) Addressing resource consumption (Elasticsearch): Blocking final = deployment=20 Again, the constraint is sysadmin time at TBX to liaise with Glen and = team to find a solution. In this case, it will take some time for the = new sysadmin (expected to start Monday) to become familiar with the = issue and to develop/propose fixes for it. The expectation from TBX is = that this will take ~3 weeks after the new sysadmin starts.=20 While this is not a blocker for content testing, the same caveat about = needing to actually have a solution in hand before counting on it = applies. Work this week: A) Continue to refine content, processes and documentation on the = revamped site B) Reset community review timing/cycle once fixes from TBX are = confirmed. C) Continue work on content conversion and process documentation D) Confirm ability of and method for Wagtail to =E2=80=9Calias in=E2=80=9D= old directories from the old website (e.g. = https://www.ietf.org/proceedings/ ) E) Develop master list of required aliases. -Greg >=20 > 3. RFC Services Projects > - Contracts for Improvements to RFC Services -- Heather and Robert > -- CSS for the RFCs > -- IDnits > -- Publication Formatter > -- RFClint > -- SVGcheck > -- Text Submission > -- XMLdiff >=20 > 4. Server Infrastructure > - IESG discussions of DMARC -- Robert and Ben > -- Mailman upgrade > -- Impact on Internet-Draft-specific mail aliases > - Migrate toward Django 1.9 and 1.10 -- Henrik > - Libraries for HTML of I-Ds -- Henrik >=20 > 5. Parking Lot > - CDN support for HTML and PDF I-Ds -- Henrik > - Migrate from MySQL to PostgreSQL -- Henrik > - Discontinue MonArch email archives -- Robert > - Improve infrastructure for finding and fetching artifacts -- = Robert > - Author information for very old I-Ds in the datatracker -- Robert > - Replace I-Ds in proceedings with links to archive copy? > - Performance improvements and transition to Postgres -- Henrik > - VM Architecture for Servers -- Robert > - Submit an I-D directly from GitHub > - Move downref registry , and integrate with IETF LC generation > - Add view of recent ballots by telechat to > - Allow meetecho to associate recordings with sessions as they = become available > - Mailman support for internationalized email addresses > -- Requires Mailman 3.1, which is expected in early 2017 > - Meeting registration support for internationalized email addresses > -- Mailman must be done first; user is added to meeting mail lists >=20 > 6. AOB >=20 > =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D >=20 > TMC will discuss the RFP responses after the tools call. >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --Apple-Mail=_0CC202DD-59C4-4B49-AC2E-7D88B26A1D33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Apologies, I have a conflict with the IETF meeting team call = at exactly the same time so won=E2=80=99t make the call today. An update = below.

On Feb 12, 2017, at 6:58 AM, Russ Housley = <housley@vigilsec.com> wrote:

Tools = Call Agenda -- 14 Feb 2017 at 1:00 Eastern

1.= Datatracker Projects
  - Expected Datatracker = Releases -- Robert and Henrik
    -- = http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan
  - Contracts for Datatracker Enhancements -- = Robert
    -- Author Statistics

2. Community & Other Projects
=   - Improvements to the mail archive application -- Robert = and Ryan
  - IETF Website Makeover -- Greg and = Joe

Update on IETF Website revamp = project

Following a conversation I = had with TBX on Thursday, Joe and I discussed the status of the website = revamp on Friday.

Issues

1) Fixing front-end bugs: Blocking community review = process
There are several outstanding bugs with templates = (filed on Codebase) that TBX acknowledge and agree to fix. However, they = have had a resource shortage (sysadmin time to prep for frontender = fixing) that is preventing the fixes from happening. They expect to have = a new sysadmin on board this week and are expecting these fixes to be = ready for deployment by the end of the week (17 Feb). 

The implication of the delay in getting these = resolved from our end is that the front-end bugs won=E2=80=99t allow = proper community review of the content=E2=80=94that is the presentation = will be sufficiently broken to be distracting from the testing/review we = want to undertake. Given past delays, we are waiting to move forward = with scheduling reviews until these are definitely resolved.

2) Addressing resource consumption = (Elasticsearch): Blocking final deployment 
Again, = the constraint is sysadmin time at TBX to liaise with Glen and team to = find a solution. In this case, it will take some time for the new = sysadmin (expected to start Monday) to become familiar with the issue = and to develop/propose fixes for it. The expectation from TBX is that = this will take ~3 weeks after the new sysadmin starts. 

While this is not a blocker for content = testing, the same caveat about needing to actually have a solution in = hand before counting on it applies.

Work = this week:

A) Continue to refine content, = processes and documentation on the revamped site

B) Reset community review timing/cycle once fixes from TBX = are confirmed.

C) Continue work on = content conversion and process documentation

D) Confirm ability of and method for Wagtail to = =E2=80=9Calias in=E2=80=9D old directories from the old website = (e.g. https://www.ietf.org/proceedings/)

E) Develop master list of required = aliases.

-Greg


3. RFC Services Projects
=   - Contracts for Improvements to RFC Services -- Heather and = Robert
    -- CSS for the RFCs
    -- IDnits
=     -- Publication Formatter
=     -- RFClint
=     -- SVGcheck
=     -- Text Submission
=     -- XMLdiff

4. = Server Infrastructure
  - IESG discussions of = DMARC -- Robert and Ben
    -- = Mailman upgrade
    -- Impact on = Internet-Draft-specific mail aliases
  - = Migrate toward Django 1.9 and 1.10 -- Henrik
=   - Libraries for HTML of I-Ds -- Henrik

5. Parking Lot
  - CDN support for = HTML and PDF I-Ds -- Henrik
  - Migrate from = MySQL to PostgreSQL -- Henrik
  - Discontinue = MonArch email archives -- Robert
  - Improve = infrastructure for finding and fetching artifacts -- Robert
=   - Author information for very old I-Ds in the datatracker = -- Robert
  - Replace I-Ds in proceedings with = links to archive copy?
  - Performance = improvements and transition to Postgres -- Henrik
=   - VM Architecture for Servers -- Robert
=   - Submit an I-D directly from GitHub
=   - Move downref registry , and integrate with IETF LC = generation
  - Add view of recent ballots by = telechat to
  - Allow meetecho to associate = recordings with sessions as they become available
=   - Mailman support for internationalized email addresses
    -- Requires Mailman 3.1, which is = expected in early 2017
  - Meeting registration = support for internationalized email addresses
=     -- Mailman must be done first; user is added to = meeting mail lists

6. AOB

=3D=3D =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D

TMC will discuss the RFP responses after the = tools call.

_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development

= --Apple-Mail=_0CC202DD-59C4-4B49-AC2E-7D88B26A1D33-- --Apple-Mail=_2FC63002-CCED-4FEF-8C3F-2641F8BA031C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKyDCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBhEwggT5oAMCAQICEDbHCML3wQsoRnZq+ROwe6EwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAyMTMwMDAwMDBaFw0yMDAy MTMyMzU5NTlaMIIBEjELMAkGA1UEBhMCVVMxDjAMBgNVBBETBTIwMTkwMQswCQYDVQQIEwJWQTEP MA0GA1UEBxMGUmVzdG9uMRIwEAYDVQQJEwlTdWl0ZSAyMDExGzAZBgNVBAkTEjE3NzUgV2llaGxl IEF2ZW51ZTEZMBcGA1UEChMQSW50ZXJuZXQgU29jaWV0eTE2MDQGA1UECxMtSXNzdWVkIHRocm91 Z2ggSW50ZXJuZXQgU29jaWV0eSBFLVBLSSBNYW5hZ2VyMR8wHQYDVQQLExZDb3Jwb3JhdGUgU2Vj dXJlIEVtYWlsMRIwEAYDVQQDEwlHcmVnIFdvb2QxHDAaBgkqhkiG9w0BCQEWDXdvb2RAaXNvYy5v cmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3JJQzreyYTUOAu9LwMVIRbk4JJrDT wziKQ+tv4PImaLS8hVWFdd8MRzybnjZ41u77sxKlyOPyDYoGy0A5A1E2uOm+t5kgdTv9T0sinLKO RcvsxB4N9uNcq9rPCYBl3xGn/mGGBgTPWyW0cFCLfS5iC1CSGKjwa4pbwrkNzE3mL5IdoC3oay9S 0in+LxLFaXsFOIgqqWyzcBmOzWC3hxB6xp6ogwRXdI9mKF4olRDwgRGeR5n5uZDOJzrLrribchqd YEsMY5swZnV2iDaNxJRkcyhs51MFbHGdl9DUkLj+t/gmZ5N9kcyvz8fCaV9i+htFt27yMx1sDf1q 54wUfZyRAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNV HQ4EFgQUubk04Qd25wDgXedXwcSHFq/6bYIwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQMF MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQw UqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAC hkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wGAYDVR0RBBEwD4ENd29vZEBpc29jLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAgPUtXouP2zFf pef0HlNYtPWbBHHHdIQRlR8nFKBhuMITuMlJU7mD3MaMsFmbgXfAlpltpbR6jHaeQHb9D+33ve0l te7zwpDct3Ibx24RD6PsxQrmqYoK7FqgvOg95XI4ZImT9Gdg6hOEFjEXReuwaDWoTHMiKCyrnbnE mzq515aUJOArqxqrbHU7ioJzGqUZ0LBMrJ4jbn1wSX8jfFvosi7T39RgBO8nxDZURKkpLt1oOPz9 OyrPy7YxvFbTTGzt+Zc7cKtpz1ornolKMTu9ypGu/m2W9CvC01E94gPcNS53FFHvReJ9AO5iSSdF NgAUM3P55Z8+/fyigqE+6rNfnzGCA8MwggO/AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEDbHCML3wQsoRnZq+ROwe6EwCQYFKw4DAhoFAKCCAecwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjE0MTQ1NzAyWjAjBgkq hkiG9w0BCQQxFgQU/PENxkD74ty2WHC5CNNCSweWML0wgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhA2xwjC98ELKEZ2avkTsHuh MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhA2xwjC98ELKEZ2avkTsHuhMA0GCSqGSIb3DQEBAQUABIIBABhonLwWAn3aMecI O3o6FJxlxPwT3ZMi0SsXcpzbJyEX6HDW1Q5SL3UjI1uqfFolOjdTjSlud5JaZp9u89awt8jVewxd OVS4d4J10OiVXpRY0SzuHPXLlATr90qZeqpDTVmptnEAtTAdAJF4cYE4yOwTSEfuOVLt0B9fXTSE H21IslwdmpMBZ9PzQJxek0eETAwoYanslumCVKzT4RtVW2K07iMKZDzSSPJb7L1J76GVJfQzPZMq I1LjyEtahIB3YOAG28ga1RF9yP5llmDWmCIV7ZbzVWq+Yui2kiDhr72+Qtuy/KezMcLSbE9KMuid ROEvCfDIOkL0mbNqUIwNBn8AAAAAAAA= --Apple-Mail=_2FC63002-CCED-4FEF-8C3F-2641F8BA031C-- From nobody Tue Feb 14 09:56:51 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018571294A5 for ; Tue, 14 Feb 2017 09:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlkvMPrZ5yLO for ; Tue, 14 Feb 2017 09:56:47 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0061.outbound.protection.outlook.com [104.47.33.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B3812949F for ; Tue, 14 Feb 2017 09:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vAfbZGALJbYYlX+6+55pgjPgN7EG9k6QHCWo+/tbMPQ=; b=WGlsFEg7DtFy238K8s+NxD7xIBro2/svqMU/mHhCveok9eEBXmGLMm0rsKBG9dGW15nK2XhiEANSXDqKA7G/UUOYpxdzZnpXq5mfEuKJgag4f+2YWY3DIshXDLINe7dwO9CIuuJMFE/m8PSv4/qAwJz5pNRKJr6NM3PXo3r/uzs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rpelletier@isoc.org; Received: from [192.168.0.12] (104.244.130.118) by SN1PR0601MB1567.namprd06.prod.outlook.com (10.163.202.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 17:56:45 +0000 From: Ray Pelletier Content-Type: multipart/alternative; boundary="Apple-Mail=_ACB582B5-70D2-4B16-B1E4-08D3A611BFFC" MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) X-Mail-Calendar-Part: Yes References: <1954030383.6823.1486734629785.JavaMail.nobody@jsj2tc403.webex.com> To: IETF Tools Development Date: Tue, 14 Feb 2017 12:56:41 -0500 Message-ID: X-Mailer: Apple Mail (2.3259) X-Originating-IP: [104.244.130.118] X-ClientProxiedBy: CY4PR08CA0025.namprd08.prod.outlook.com (10.173.247.139) To SN1PR0601MB1567.namprd06.prod.outlook.com (10.163.202.17) X-MS-Office365-Filtering-Correlation-Id: edbbdd60-a35b-44b7-41f4-08d45502d74e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:SN1PR0601MB1567; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0601MB1567; 3:prYPo5rXPTWBnSRGby5lwPX84YJeDje0WaVJmvozp+GORuI9xRstZ2A16VtYF7Y0f9Ah9nm15Wo48qZg2XVwT9p8AjVTdWar5Xwi6p2o1rEiC9BBmYnB93XH44Dz1yDqx0GumVFypCE1CC4fN7PH9nkJWpQjMPuhQ05TnKJ/Le7sQeJMRsoWJK5RUTG4vG2jAzcMnbpwfX+tLIgtxUiJ2d0andaHElvITMG8e7SOFOrrUlTFdbIw+zoTp9kqS6FdeRmUOHKXET/YwkfUmxRS0w==; 25:enVE0daMpa1A1Semic0f4SrB45QvH/R2ioAmVfgIpYqUkXvXW8LuuaNoURLhWiaomjg9VT/FSYFuQB5tlXWE14c42/C/EXTKQCf0NVmvTSorWAqmUV/9B48cju40B1LRPyrbyIxD3PENHbdxFWpKfhVy23nnTPpcgFz8j5KurextwgCIDNjfXOUWesaIPS+6ofcNaw5A2l/b3yUGbi89h8HfTEabkckcfBWJxMNTx/XgeOxijTlGwc2uJ/dZdYZRKEbr2c5JfnXv8P1umZDXcc4PA6RNokDGUK1dbPEIdyGgsPG2qCzIcj3fr6s4F0VypFm8mf8fBQ19rHWhP/6iGfViCSfJS/P9XObzM/zvKGYB5ucyKD4cW/ZSSQcwqBdwk22AeBQ+dCp2snv8eO8DA4OVOQP4rxRNV+zDZDpQFr3jbYQXBamDkVXE01uu2/9IhWz0wU2KJqHh1GnidTeEhQSIdBIP59zZF8S5Q+8kIeatBRRkONm1kHKjQxA5Ji/7ZTPi/4JLiGt9w3pEmMC9/UaMCfzJFFp83/HQabxf5dmvrBcsuYxmu/TgRTpD5nAspjGR7EKjJObVzftvWyfzKQ== X-Microsoft-Exchange-Diagnostics: 1; SN1PR0601MB1567; 31:leI1f7zPsEbooj01vgf9nD7vTXH71YDYqhVI+mY6xanjPwj2NXVw5MJH9cQCNKfxqEfwm55K+x8d54LSDezrnnr9eZ8EYxFJmQJifEBXNKRELPbrVEprnRavCT/ntTIwlLOoPHhlUfftWrrypKMTYwsps85hxIwWBzuuKp/zxqkPtQ7FDU6Y99vdEsdezpJCP9IsoByZZWT6T5KtaYe8GMdQQjjfPoZF/ErWZQfAydD6ch1xymwkRCsqzLSdHgGLGdq9X6iBhT2F88Y7Fto95bUk/SpKboEoOsDmw0l6MESXoyil0VZHn5MmrPFKqz7o; 20:dDKcBz9mzgO3oc8wTlpWBj0hR+3nVzoKSCX9pIxYFEwqzeiv6X8jnTsLge8+bYS3YUuLmzZV5NQkl/Ur2gzl9I54vhi6SXpUhtrpccNdttfgJhh902CY8J4aYalKcJyPmgCju3TQU6VgTU5f+JwAAtGTZnyJ1sCQAXZllAMrQ7TFU6TDWZas8nk21/cKmvD2jQUpB140Xnvth0vNu+sAUDdy6MnqEGSvJfqnrWUpGaoFLFSv95a2R/L+IaLT69qhMpID9oklhUp5SQ74XuwpawYd4XOtgO2ouXu8QjHLp51L7TY2u6jEBn2pBvtVFiXqeT9qxFG6bDxIdelQgbvtUFLsxlcA8+bglHw69ZPAk20pxbfLVMD5PdZkJpf9wDp2L2TJsWfj5JeUdWvM7YgIRpGsZ70C6/FP5wtiCo4/wm3ytkcjpMUlJ2IhhES8o534ulH9BirMoxfvsoiPIeMjpFSGCFrjGq6IcZhaFIi7RcMBbIibFHIWIywhjw3cIzb0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(118321135141591)(94707916325470); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(20161123560025)(6072148); SRVR:SN1PR0601MB1567; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0601MB1567; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0601MB1567; 4:SQ7uzJ+xF03ZAm7T+P4RFtiW8j1ixae3h9BxMNwnblcjxBqx+iwPm6VlrmLdVIwq526eYFvd7cYOGAE9CGLxNyhj5T/8K67JQCc0ujKnecI+kBbQrZudcnUOM9HjgZAjngg+jIx9kpTELqQWsTDSVIgO+0g8N0WXprAZFXbZ/HsDS+/w1PsG6nVTYQTmh1pjHzDBUqkb970ZSFsXzui8fdE0ZL9qqLy+Qyztd4xaFAxkftX74Qs2TPR+XPFsRLHkMa+ITDnMRKfHr5AIy8ZjVtdimCZJedM/3ZE8LHrCCc8zNUnLHz8LdAyPzOVROTvcoM1fEdjy35ywxaIfp9VLrUz/o04Q521LhqRnh9+SoIvyYl9T3EFmUgkjT864F/xbxeyLylODGGTtmseu3hgqV+TdajU2DnTwDbL8wPxPgY5p48cDhxpE+OM8/ui/umprEsf3bRZEPmgHxmdikIRD0VaxMjNSI5Mk2Lue3UIDRn5ZL5J5FJ4yhzgnH8xD0kKrSRcxJxvkqCINQ+h5SmMH9XTauiIIHFflGT3EyDnRBeq1LuazAWAWQFLt19psW1u3fDr5HsZdPwIgEjHefU+IodHdD3awVlBaYhiZGIzWT3Bcwpt5CfqLmxGFECmNxAij3OK2xwqMq5k8mx02jLFIDokbyp4GI/8tpcJfP/m7jMOM5nkFBCpvpJ9VmtX0pNH+nBgkvQlBuSbmFlnKSEoVxg== X-Forefront-PRVS: 0218A015FA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(7916002)(39450400003)(199003)(189002)(377454003)(92566002)(81166006)(8676002)(6666003)(81156014)(38730400002)(229853002)(36756003)(6916009)(50226002)(57306001)(2473003)(77096006)(6306002)(68736007)(110136004)(25786008)(90366009)(606005)(236005)(6486002)(7576002)(84326002)(82746002)(81003)(86362001)(53936002)(83716003)(5660300001)(450100001)(50986999)(101416001)(42186005)(106356001)(7906003)(7736002)(105586002)(97736004)(189998001)(512954002)(3846002)(6116002)(117156001)(260700001)(270700001)(568964002)(69556001)(2906002)(76176999)(33656002)(16799955002)(66066001)(5890100001)(24704002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0601MB1567; H:[192.168.0.12]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0601MB1567; 23:jWUIKuwEUinona/hvchcCvys0uV+DorGFPIiBVh?= =?us-ascii?Q?1J2UEl7ib0sXGctO+cMhqIk9YsmfH9QYEd5U1ftBlNg0k10JTTw3lH6sawqw?= =?us-ascii?Q?WLFbsgXqfN+BGcwJPiHnNXHiEpybghx7URDhPTqdtzLCaLnzbqrcbG97/Kfd?= =?us-ascii?Q?3iZOvibXBnR1Tk7/fn1ROUtiYK3qiUwF9kg720gaiXYmP3vk65oyZ6UvY2gg?= =?us-ascii?Q?TJDcQbKCqjIvSaZV/bsknDp4TF8eVCnlmBXpQpX/TxSOUNsqnKXG6CnukKlr?= =?us-ascii?Q?QZUWrHepviMXGebb8PWW356Hde0lPHtwJF9OSkHwb9lfRzq8GhJWiGNfIjDp?= =?us-ascii?Q?k0Pr9eqdGTUHSsP7VXYputxA40xwi6uyz6JIn+dE1CYji/Qv4+33L3NDv3YU?= =?us-ascii?Q?PGKFOB8FGjun3rG0uDjllwCqhN6H0xbAzFlJ1o4X2IAPUVse6OFTo3ihVPta?= =?us-ascii?Q?DhkzOIgkE2PH1p97S7HPovtwD7Ndd9NIrGvLBBLwXW6LV8HsUrkAaKi6SOpL?= =?us-ascii?Q?mcsDJoqf0boOOe8W2aHKx2DByDpJj1ZfiD2qoFBShKChL69X3GUI3/gjUdiV?= =?us-ascii?Q?JBm9bqlK36uYTdmD5vfjig8+gOBhcjcXy3pqVNZt2cuRSxbtONDPyhQ1zoc4?= =?us-ascii?Q?AlB4AAKyxhBCCn6owuJxIdj88CZGDg4dJGkGTklXM6QOXVKTpc858O+kNYls?= =?us-ascii?Q?W/oL4i7s8KE7gDZn5YGWa3Z7++muR6Jr40/pvsKEzOiRDjlvjieJWCaUJIqW?= =?us-ascii?Q?uagN/uJFZI/ymlWt/RzaZlAZ41lX3Lu2jMnBj1r8Eqhue7XYKfu+jBHRCVP3?= =?us-ascii?Q?ssiMYV7YmsJOI+w5nqTk52VeiBZtlk6W183a9qNrxloicvgGTsDKpoJsrt5y?= =?us-ascii?Q?KIsqj8CkrYg19eIm+AWcTiNTsM0USMynWdN0HkrmS7BeRzNsYfHWn2mg2j4B?= =?us-ascii?Q?aSvzRRnjbb/Q1Cd0yuDA7/ZRd1XOjl2iwCj69OK1jP0fb12nwjqyMi5DB9t9?= =?us-ascii?Q?5aJrbvOpdyywjrmg5usrvo4baPEV0Z+S+onyzSzC94J4I6Ru7c4w0iHW9SDW?= =?us-ascii?Q?3F0BY5bEXIc2PHVojKf4L1EVbLNSXhRf5zcfQmORfslfMqWxogZJ/VKBwUng?= =?us-ascii?Q?WehfZQKuVPM4ndSpQSk4WxltAtjJX15/4vrDPXTgfzIZehUm0uAFqvX7tvqP?= =?us-ascii?Q?c12XSVIF8uWg6AcJZ9aBdqyC5lAkUZsFWa7HCZ1CoDy+tGWp0E3bkpFeogiD?= =?us-ascii?Q?z/COI1W3hN4VdW+4bszB/RdOMNILfiORLhDELRn0wt7i5JfLcN+mCsfIG3wf?= =?us-ascii?Q?1dm9p/ElExA/ovnNPG1QYDOIKuQ7cSAEE0dLubC+7Y3HNyEsUYQ+9bYyJKpp?= =?us-ascii?Q?GRSgRy1940UcxOlaRyqqYoaGMVECKYPhqe4tJ6XvWth5qi670VZ4TZf5fWfo?= =?us-ascii?Q?GGTVV7fA0zPWApFwDqERO2ec8fnivm4M=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0601MB1567; 6:0iewfVKoW0dMIjPI4axMA2p1hKICvV08Rq42Sj/JRr339sAxwKqRyXRytp2hRxCLq4VgRx75TOjTWW1iJM6QPe0RKy+Dm5jTL9mGcPY3csYEJ3xSUUo+PYawXXg6urJRPcor9VE8gy5FOgXhe8wSsb548FvPgvXTv2arM4pVQY2Wh64x5IxtAZu1sCxoRR4IxqDNMZ9I30ORJSLCrgu76LSk1y6MMeKhYNM9lXUqFktXAbtoTqQSIE+NHYE+IgMIgNVNxSw4Q6Blx3PZ3CzukH76ckDJdLDrh7cxjuR4nkwXi6xChDaRn4ikTzpVM1seUKEEMJS83zl5uj92V1GHUzZCXezQKvYew7PKoV+TR1Ipt4M3KaX/gsZmo0OTnn8PEFzHlYhmuTQHH/iZ2O4A5Q==; 5:wES/ZvGjuH91ze2rJjgl8pjizgPgi2h4JlxKZF7kesyxl4PhsXNstGJuh6xNAIKh4m5nZxSdM9LvIuK8IrHG5OgFw5ulqmrhjUucs5w8Bcrig7R1n+FK2RnvLuwxFgEGFTVHdexgC4Ul9bLyvmd/Lta3ajT6MT6LMD79XjqJwy0=; 24:nlv8MlEvh3hD6D+O0OI4QjdA/Wq4QqOraLiMFUtpfwU82PdJe2a1oI0deoSUMZGCJXXlRSa2b+q1UfEkPi/FZCnWN8uXVKuVLP4AA9aSfKk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR0601MB1567; 7:ja4W/t0v8u3OpgAlh4AO2kSpsfdTcw1Khc3Neij1e1Tpy/YRAenRUjlncX/ueDXYJ6nVD+nZbOI0zo4tRG8B9dKD2lsNI3okCrPmLT+d602PXvot6hmHufjRwrSQOi7cogq6N+79iJj9ifDoR5Z+nC9gm6ExgnSawzBOJHHrluz+F7pYibnh+apSPwdSZIIcGlbE9G1er1g17eo9jvG3AGXFoCy48cvm3XMPvZ6FVTyiFKIR6VXP4LGCyDZRI+4mbIXAt4h5Z926HNvtjcc5Ih8qhie4TdkKH+ZZ9ZDGee9L1fUMsE9f0M9lWgpbaA1JWy6NM+OmMtQ35SY5sxeBrrcgXNIHxql9MU1y6KOQUzW/sJ8Jnp1xDidY5IlvqY8gSZi5Hi1AZrBysKUjrhs/3rUDAqgFzQItl/hwFRdOPD4H9gtl88M5ZCtOnYNj92VK7I6ztIIbSCnhs70pW8J16/Jbb1vFo/QRYBqvB4h4ZhEQQMlkhj8NbCsDENTHsy/pGmXOT4upLY5ygZr754ddRA== X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2017 17:56:45.0943 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0601MB1567 Archived-At: Subject: [TOOLS-DEVELOPMENT] Fwd: (Forward to others) WebEx meeting invitation: Tools Cmte X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 17:56:50 -0000 --Apple-Mail=_ACB582B5-70D2-4B16-B1E4-08D3A611BFFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" > Begin forwarded message: >=20 > From: Ray Pelletier > Subject: (Forward to others) WebEx meeting invitation: Tools Cmte > Date: February 10, 2017 at 8:50:29 AM EST > To: > Reply-To: >=20 > You can forward this invitation to others. > Hello, > Ray Pelletier invites you to join this WebEx meeting. > =20 > Tools Cmte > Tuesday, February 14, 2017 > 1:00 pm | Eastern Standard Time (New York, GMT-05:00) | 1 hr 15 = mins > Meeting number (access code): 821 720 794 > =20 > Add to Calendar = =09 > When it's time, join the meeting = . > =20 > Join by phone > 1-877-668-4490 Call-in toll-free number (US/Canada) > 1-408-792-6300 Call-in toll number (US/Canada) > Global call-in numbers = | Toll-free calling restrictions = > =20 > Can't join the meeting? > =20 > IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. --Apple-Mail=_ACB582B5-70D2-4B16-B1E4-08D3A611BFFC Content-Type: multipart/mixed; boundary="Apple-Mail=_D257D7F9-171F-4574-99B7-18E627B677E0" --Apple-Mail=_D257D7F9-171F-4574-99B7-18E627B677E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Begin forwarded message:

From: = Ray Pelletier <messenger@webex.com>
Subject: = (Forward to = others) WebEx meeting invitation: Tools Cmte
Date: = February 10, 2017 at 8:50:29 AM = EST
To: = <rpelletier@isoc.org>
Reply-To: = <rpelletier@isoc.org>

You can forward this invitation to = others.
Hello,
Ray Pelletier invites you to join this WebEx = meeting.
 
Tools = Cmte
Tuesday, February 14, 2017
1:00 pm  |  Eastern Standard Time (New = York, GMT-05:00)  |  1 hr 15 = mins
Meeting number (access code): 821 720 = 794
 
Add = to Calendar
When it's time, join = the = meeting.
 
Join by phone
1-877-668-4490 Call-in toll-free = number (US/Canada)
1-408-792-6300 Call-in toll = number (US/Canada)
Global call-in = numbers  |  Toll-free calling = restrictions
 
Can't join the = meeting?
 
IMPORTANT NOTICE: Please note that this WebEx = service allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the = session.
= --Apple-Mail=_D257D7F9-171F-4574-99B7-18E627B677E0 Content-Disposition: attachment; filename="WebEx_Meeting.ics" Content-Type: text/calendar; x-unix-mode=0644; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0ABEGIN:VTIMEZONE=0A= TZID:Eastern=20Time=0ABEGIN:STANDARD=0ADTSTART:20151101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0ATZOFFSETTO:-0500=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20150301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0ATZOFFSETTO:-0400=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0ABEGIN:VEVENT=0AATTENDEE;CN=3D"Ray=20= Pelletier";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:rpelletier@isoc.org=0A= ORGANIZER;CN=3D"Ray=20Pelletier":MAILTO:rpelletier@isoc.org=0A= DTSTART;TZID=3D"Eastern=20Time":20170214T130000=0ADTEND;TZID=3D"Eastern=20= Time":20170214T141500=0ALOCATION:https://workgreen.webex.com/workgreen=0A= TRANSP:OPAQUE=0ASEQUENCE:1486734629=0A= UID:709d153f-56bb-4829-9d66-20860ce32fcd=0ADTSTAMP:20170214T180000Z=0A= DESCRIPTION:\n\n\nJOIN=20WEBEX=20= MEETING\nhttps://workgreen.webex.com/workgreen/j.php?MTID=3Dm8dee4f16be754= eec5ea1acbb6af6c36d\nMeeting=20number=20(access=20code):=20821=20720=20= 794\n\n\nJOIN=20BY=20PHONE\n1-877-668-4490=20Call-in=20toll-free=20= number=20(US/Canada)=20\n1-408-792-6300=20Call-in=20toll=20number=20= (US/Canada)\n\nGlobal=20call-in=20= numbers:\nhttps://workgreen.webex.com/workgreen/globalcallin.php?serviceTy= pe=3DMC&ED=3D359850237&tollFree=3D1\n\nToll-free=20dialing=20= restrictions:=20= \nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't=20= join=20the=20meeting?\nhttps://help.webex.com/docs/DOC-5412\n\nIMPORTANT=20= NOTICE:=20Please=20note=20that=20this=20WebEx=20service=20allows=20audio=20= and=20other=20information=20sent=20during=20the=20session=20to=20be=20= recorded,=20which=20may=20be=20discoverable=20in=20a=20legal=20matter.=20= By=20joining=20this=20session,=20you=20automatically=20consent=20to=20= such=20recordings.=20If=20you=20do=20not=20consent=20to=20being=20= recorded,=20discuss=20your=20concerns=20with=20the=20host=20or=20do=20= not=20join=20the=20session.\n=0AX-ALT-DESC;FMTTYPE=3Dtext/html:=09 
 
 
=09=09Join=20WebEx=20meeting=09=09=09=09=09=09= =09=09=09=09=09=09=09=09=09=09=09=09=09=
=09=09=09=09=09=09Meeting=20number=20(access=20code):=20= 821=20720=20794=09=09=09=09=09
=09=09=09=09=09=09=09=09 
 
Join=20by=20phone =20
1-877-668-4490 Call-in=20toll-free=20number=20= (US/Canada) =20
1-408-792-6300 Call-in=20toll=20= number=20(US/Canada) =20
Global=20call-in=20numbers  |  Toll-free=20calling=20= restrictions=20 =20

=09 
=09=09Can't=20join=20the=20= meeting?=09 
 
IMPORTANT=20NOTICE:=20Please=20note=20that=20= this=20WebEx=20service=20allows=20audio=20and=20other=20information=20= sent=20during=20the=20session=20to=20be=20recorded,=20which=20may=20be=20= discoverable=20in=20a=20legal=20matter.=20By=20joining=20this=20session,=20= you=20automatically=20consent=20to=20such=20recordings.=20If=20you=20do=20= not=20consent=20to=20being=20recorded,=20discuss=20your=20concerns=20= with=20the=20host=20or=20do=20not=20join=20the=20session.=0A= SUMMARY:Tools=20Cmte=0APRIORITY:5=0ACLASS:PUBLIC=0ABEGIN:VALARM=0A= TRIGGER:-PT5M=0AACTION:DISPLAY=0ADESCRIPTION:Reminder=0AEND:VALARM=0A= END:VEVENT=0AEND:VCALENDAR=0A= --Apple-Mail=_D257D7F9-171F-4574-99B7-18E627B677E0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii"

--Apple-Mail=_D257D7F9-171F-4574-99B7-18E627B677E0-- --Apple-Mail=_ACB582B5-70D2-4B16-B1E4-08D3A611BFFC-- From nobody Tue Feb 14 10:09:44 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F24129689 for ; Tue, 14 Feb 2017 10:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPL8Ly5efJBv for ; Tue, 14 Feb 2017 10:09:41 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0065.outbound.protection.outlook.com [104.47.32.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538831294A5 for ; Tue, 14 Feb 2017 10:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qy431iWpZgR3u63hwCjaNcYPPZRLFlHeNYW09XLaGQI=; b=YjDG12/MesBswDJa5eN09rC8XZWePgncEm4QFS1IvZ+HFwGyFGyWnQX0eGfr75ZLoS89VnyxAJeV/JJLFM5h6lGYZ2OkSawNtwY/SA+NUTP9QWI083DwkQpsfjQlRhtf9qwAUxZ6ohak1sTvjtPmDhLirrp7c8BHStM8oBBwuXc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rpelletier@isoc.org; Received: from [192.168.0.12] (104.244.130.118) by BLUPR0601MB1554.namprd06.prod.outlook.com (10.163.211.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 18:02:57 +0000 From: Ray Pelletier Content-Type: multipart/alternative; boundary="Apple-Mail=_68AE6AEF-96B4-4478-9105-FAF2D4AAACF9" MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) X-Mail-Calendar-Part: Yes References: To: Jim Martin , IETF Tools Development , Henrik Levkowetz Date: Tue, 14 Feb 2017 13:02:56 -0500 Message-ID: X-Mailer: Apple Mail (2.3259) X-Originating-IP: [104.244.130.118] X-ClientProxiedBy: BN6PR16CA0030.namprd16.prod.outlook.com (10.172.26.16) To BLUPR0601MB1554.namprd06.prod.outlook.com (10.163.211.144) X-MS-Office365-Filtering-Correlation-Id: 25c3af19-2169-4f22-4b56-08d45503b53b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BLUPR0601MB1554; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB1554; 3:hbCQDxlBTbVLxf8lslIBrWo1NFndJGeyyMKgq5LBOvV+CUMXatP/QuxvhG1a+rNRM1PPt5cwo1O/Q4L0fu5Mje0BtO/DQYoI5fz/LkZkN0lmlZyx5BARzjJyYqdj13zUNS6o7rO2aLIZNVJP3sDGGXMHXtBF0sc58wI/6BOVHuI9cE17bkL885fppDTLMEK1QQ/iW9AEtQNBYsOIxw+RztsdgEI1VYn0YM2AQM/eFbhOyCd4AikbIHqtzeTpMjVpkNyymdWiwJl6IY0qPL/ItA==; 25:bIdh3rWucG5iNA7UoSvfShVf19IpWBLlpREsEAW9eiNagXdTxJa6TzBgBK52CVWN4lqRLbkUK+xeuq2EsKwfWW6AfSy8C6FZQdPSTkLn6tcN6doLaNnJoSFKAbg1UdG6JvJ1wkDt/EXtZRrbEZL7dH7gES9RXvaX1hckHnoHM3V4IDxz7H3Wam7alh8f9pyKGa9Xv8cdyyMKqrtItVosmHFvXKzghnGXUhENdzPgFa9/j8Ml2Vhd4j6+ALHd7JPmvH2p9lXBtvmEQucITf6geu22RxplznAab2HGxZ7eZb0pKcQqzUFec/CW2ZzKmbVDwYPf2G98o+QL7/8Xl7aHwd+Rw/hgvvp51WRHudIdvwmVA/RlZbJ7Z97Ch115FrPcHNX99k7W19aulIWLNjRmTIrDJsAHqnN5yeUm7WV7AljookO54YxoR5tSRJYsfwrrxh9I4ntMt3y4wSBcr4X0St98eM2YAr/0Xp1NdjTK6CKc7ftwiHhSJbqRBQlijw5TaBpQyvUvW9qfwzwam4ikliwmkLDRyj4giwF2cUeMRIJfsxqQGx+dM0ykA9hVAnfvmZSnx+MmY9MsZ9p2M3Jf1w== X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB1554; 31:PAQJhN5UDxgDNS88YDoB3rnHt7q2gaWEKdxoSuchlkJThFIKhx2U0+jgV4hZhSWPZYJQQu8lxGKnRjd44BxV8jsavn98Jl3MRzZHaJrRiU9kQB8jMt5q3akS3ovuK4daUVFK5BXW2EM7ZvuSKIlNn0tpr5hpxd6R4+f84YC4ce9eqnAXlyuIV4gc38n1bPaEmHw1DqKyoWcvHD7zFOUX7ePeFiPTzayRKRzXa03XZHeHPvswK7xBrA4AUacc30ha9UqWYVFIMKrfzKhnaLMaCw4B2k8BU1bP6w3jcobECdMr2s7sDFlbufTSdzPyxKrQZd9QLH2qpQJ0Qz9zy8E8BQ==; 20:Y6waQDITf+l4FJ3f7rXhZuPYv/NXBBTLUgBLrYH9sUy0n9py0igUDnDzV9MX+ZYnni+ZX1RXBtGuG12ug5DOVPlG5Wnn4FgDN02YMQ91C58klMUeVVc6qKMYNYPn/zofmImWbVnL5fDOoineBWGLdChnpGFZYbAJZXqKQU9LQ15EUsJtDb0RDmkOO57FWcfcTof/JRm/FDgGr4mwegYKBdhU5K5b2wVB6STyGgXBLxd3F8ML9UZGRaVJpkGAcgnYP3qIZ4uJE2c5yZfdWxbu8zn3Qu8+0ygg6ofW88T22Qx/VAWvfKBE8JE9K4xgjduo5RL5551eZk579A95bMhjq764C4VTLGOTpJ/69rKvc/pN6uLmn0l2heqGEQg8MvqBucAm3+IqrYvUPcSskJ6AHQMQK3FXznPkpFuSyaD3CVLskWNGduAaeUaJ5rfyXMsowXmMay3c13Hl6yApfwByoRp2jMlvecNWQolAPdUMVlNyhlksz93HumJdPjRcaBn3 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(118321135141591)(94707916325470); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BLUPR0601MB1554; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0601MB1554; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB1554; 4:gcbmVDBq/3+zRg03mUasBJb5XGVW6IQRXtkUJiLMEy6HH9cAQvaoi5c++TVXCNedz5EaU1u6mlJRN1CdhusbAFKnyPCoanh2JBU9jHzSj2WUJPj/pQBNp4tIR9SWcfSDqhRo7yxMlywUwrEnJVzV/w8duslEH60FrL9U9Q6n+YnqFhTbmd7k5PcQAsfvXaeEBYJLrnhHE597WoVleyQPkEdTh8mkVUPZDrSlM8K8T7gv6GRHbsWlRcpkycAwOVp/9+F5pDeeFyn24VN+IACwq7qzhulO07GIgH30KHvEccikoZrCDD8Yb7LbgI7IJzWDLWsaYZ4San+/a548AADZSEwiLLSCrBotzo2VrPrWJhMIQBdDO4sgwx/kCdGKNrkGQFDWr0nOqY+J4oFyHaNETuH5P6TacQPE03aEffzzeETOESPgp8QBUp9sN7yZdue+u1dCU5YqTeF+Ydca0m40/E5jFsbYjMILvy1Dy8cD+QrpAQPKoKTab+4XQgTxa5ZKhAbELl9GYyqiLxexwr5EzjUqsk4rLkqSi3uP8CIDF5bpS9OFTV73FtgIEHmiK8HvwXeOkUJyTK3nV1qf5a+sJ6w5mYEOCq/jDxlK8C8DzQoLy+MgWl3dj9N/eno5T94zKolF6piGpneNvxqQxUL2+amUPJnssjLR9D1Y/8Oi6IgNrIZnw68vb81Pxb+jPYtpt/nz/KE9ENBGTJSH0bOLcA== X-Forefront-PRVS: 0218A015FA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(7916002)(39450400003)(199003)(189002)(377454003)(568964002)(270700001)(16799955002)(68736007)(5660300001)(117156001)(81156014)(76176999)(92566002)(7576002)(53936002)(50986999)(8676002)(81166006)(50226002)(101416001)(33656002)(189998001)(77096006)(90366009)(606005)(229853002)(260700001)(6486002)(25786008)(105586002)(236005)(57306001)(97736004)(6306002)(42186005)(2473003)(106356001)(512954002)(2906002)(82746002)(38730400002)(36756003)(86362001)(3846002)(6116002)(7906003)(84326002)(69556001)(83716003)(5890100001)(7736002)(66066001)(81003)(24704002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0601MB1554; H:[192.168.0.12]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0601MB1554; 23:PGKxQlZvZdlnQ3AIH6X1hlf7/56Y8T3O1th3cWN?= =?us-ascii?Q?TJ8/QC6I3kxZn/SukFjxL7IUUhYYCUz8SLjoz9MtS+nRputPAgt+VDMgalbg?= =?us-ascii?Q?dUXaqMVSPkKX7JhYPBOr+Z3Q+aVFyEiLvCoubHFG9XQ1RcE9vO/8q0PvZlpA?= =?us-ascii?Q?lqJOWIT/941I8nc6QWCVV86DLVjDiq6t5Lr5TTvxwLC6mCSaoBUwOdYhqeK5?= =?us-ascii?Q?XiExNTXAAS94pUovkWD86elH0PoebArbH0kWxNQmYj9UT1o0cG6GiqtiH6x0?= =?us-ascii?Q?aELjrOW03F45+JjPIBblDGmRGspcAmH46Co0QYkfWFSg1CwBuJiBjqP2WDZv?= =?us-ascii?Q?ksEgA0YSrHVp0zgdwkCEbt8BbdDK3ByuEROPaaQ6XJifqj5x1dmjwK/4uq0T?= =?us-ascii?Q?ZywAzzVdCLNVSov8YEuTVlA2VbLS5dtTX1em+FT1TdIhFwbSAMHm6ulmwQAP?= =?us-ascii?Q?xU2eGDxjsksegZBzIA7EKGV9PesgdsUQ9sEzVXR8hbqx0ehEazn0uUkcWUlc?= =?us-ascii?Q?d9fhIGXuQ+gutKX3Ov03uAOs8Aus1Dv96dtYUhwNL1EQYNq3eePvH1tZynEo?= =?us-ascii?Q?HNYHqWHUG62VumisrGNv+RK5rn+szjW/aKOTmnjAmC8EE2zARGAa4rmHWYlg?= =?us-ascii?Q?GY1TU9YKznhEMo6rQgc7d7mbExI3AAr5gQIzT1EczqkU8C1ZPNSkYvqFgC7m?= =?us-ascii?Q?6Mhq6gQPxQm1784v4KgkFQFGDALeBRuK8vX+ZBk+g90fHjwZKDPEuLpAoQvb?= =?us-ascii?Q?kGZr0KTiATsL2Za8yYOvmzO+gaoNme040ax8Kx6HBFvNln7MiVOEkNqkjvNe?= =?us-ascii?Q?Bg2VM3RyntV4mL6XMMqShTXbBEJ4VcRpAp0I/jbHKJjC5HvURsK3cl1cpx9M?= =?us-ascii?Q?0DNn16CUaHOaR2PI3uOgR1qdxa0fleWxazOrDu2+nsACBAhY5oUZn/0X3/D0?= =?us-ascii?Q?I0fW23vkxvwL5KjRsSOiCVfVSzpbYr1kFnI3FGkuOdZw4qYYabP8+1QS82NB?= =?us-ascii?Q?Z1kAK6P5LMJaAzb0rNVhp3Dy+k4Um7VrEILlZ6lHaFQxAn9kWrGg2/fYVrk3?= =?us-ascii?Q?H/wtrG3GMGHRAJ4Ixa2Bh2QbRbjWKwNPLsHGK/5h3+ws9W/1DzahQD1iRw73?= =?us-ascii?Q?WjIWJSAf/sV91Q8NXwiBU8amExhcuzqruO9shQiY/sNZeiMXCUfe1Neiws0G?= =?us-ascii?Q?ju7ChMjJs57hGP4nsA8XAMi3C/9USNTyyABcgHVEkymHNMEQy+igEjE2+DIu?= =?us-ascii?Q?/y1bqUvQglbmT8k6L3Tn6WWN2Ti4XZekeS5hT7gj6yjSSYJ4ecEtzCsTNY5S?= =?us-ascii?Q?1lBAJbQ8sKc14GDy35koEB2tJw0ZTSPZdHu1HLu3SLWoxyfFiFPR1pE5sRyl?= =?us-ascii?Q?E6R+3zuPh8FxBtryJ6Q6nEdIWXeQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB1554; 6:2cc+vopQdC9OS7m0uaBf5be3gUmMnVFQDsPtxjBqbsE0DC1TRdEX7cdPUKVS0qzr0A4etsxiug7l7oU0KV1u0mRr5SgOVYqhfQYDyGOzcXqjzpkCzpBn3wEUIvZroYt9BhE7w0a97qtuk5Z39yMpG6dFJ1Rfr4p0C1FbDBM6Q03uISiYUDlzM+7yKmlXmiSdvOhI6/XxF3EP2lqnzH5BbxKh8khRl1wXdXbsDUR7BrjZDM2c2cW8ElAuIyWCnXYM0lPA9P8wSUYRGTnT22jG+3D8ZSIswWnxB7TZDLFGxzw/trcgToAVc+VJDVf5cNt6cEomBpajMkl6d3sKZ+oy4yTw75EF7UIfkafBBS94zxJ/H8oUQKGT/DIdGGdDvFO8eo84LXwZFdyOHvHe/VmRzg==; 5:z9tzWPextQwvUXK0wSYs1Rl7qTBobKM8adea8D/jpKEpHOzeXSUivE08kJWtL4CGwpVbquI7eyd4r2dNAQYtA7L0AFQD0ZNf4vE04EWmnBA2Ojdy9M0MSvSfyfXCS4fTtQoPNicHLq4wlScARmmJZzBbg3sxtwE0ZFxgDw8H78Y=; 24:B5xzWSatIEaptf45HNl1mxkrrDjCOri0I0qDJH2YD2KHgSQrJOH5Tk/nfR8UKdMOCTNTr8hXWLFVjfcjvQg9C4uAZmXrM+5UJlmfiU46UNk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB1554; 7:H0K0mGH4AAYrDFoW96u+oL/D8bN04Lsf4edn7Q0pM1hhHjbJkMA47zchLCTJG+VxDqnrR8A6FhrIPydwyc17MmIi0k3Nw2Uku5pds8Vlpj8IXjW3PFC+ElfePWuEFK7EaOSRHmxfhqI6t2wIjUbBO2ozB7ofc5n9h7ZuFyZRoBFa+O1mEQpMo23nzINYO8mgu1bC8btdF5rKaNMQ7mUAKR4e7K5UY2lurMPNLdUUtvKG5u731RV1kt+JL9gQU4yUsduN495HovknSgbVWZQSRqk3b7OEvgSEtP+JQu3IN9E1tO50WBYklYmr4fgm5UU50Pdwf5w87hTLkToYWo4F3S1mql1MWqWOED3ODvNmzACn9xA/len/3zp9nVmajLv6PSXGBWH9jVBAWL/NoDwC2ke2FA+z9/PO9wy7FF6q+9aPlSzxLdK75ac9aoAz/rS7NjfHiuWglpZMgLDestIuPLhHYvY2Ba7BqTX0ZGCc/aE0WcT2iNKMOUzRltdNNrlPi6JnCSxIX7/KO5MCecSAhg== X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2017 18:02:57.6157 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0601MB1554 Archived-At: Subject: [TOOLS-DEVELOPMENT] Fwd: (Forward to others) WebEx meeting invitation: Tools Cmte X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:09:43 -0000 --Apple-Mail=_68AE6AEF-96B4-4478-9105-FAF2D4AAACF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" > Begin forwarded message: >=20 > From: Ray Pelletier > Subject: Fwd: (Forward to others) WebEx meeting invitation: Tools Cmte > Date: February 14, 2017 at 12:56:41 PM EST > To: IETF Tools Development >=20 >=20 >=20 >> Begin forwarded message: >>=20 >> From: Ray Pelletier > >> Subject: (Forward to others) WebEx meeting invitation: Tools Cmte >> Date: February 10, 2017 at 8:50:29 AM EST >> To: > >> Reply-To: > >>=20 >> You can forward this invitation to others. >> Hello, >> Ray Pelletier invites you to join this WebEx meeting. >> =20 >> Tools Cmte >> Tuesday, February 14, 2017 >> 1:00 pm | Eastern Standard Time (New York, GMT-05:00) | 1 hr 15 = mins >> Meeting number (access code): 821 720 794 >> =20 >> Add to Calendar = =09 >> When it's time, join the meeting = . >> =20 >> Join by phone >> 1-877-668-4490 Call-in toll-free number (US/Canada) >> 1-408-792-6300 Call-in toll number (US/Canada) >> Global call-in numbers = | Toll-free calling restrictions = >> =20 >> Can't join the meeting? >> =20 >> IMPORTANT NOTICE: Please note that this WebEx service allows audio = and other information sent during the session to be recorded, which may = be discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. >=20 >=20 --Apple-Mail=_68AE6AEF-96B4-4478-9105-FAF2D4AAACF9 Content-Type: multipart/mixed; boundary="Apple-Mail=_B3F3D493-5015-42A9-9517-5C42C3499C6E" --Apple-Mail=_B3F3D493-5015-42A9-9517-5C42C3499C6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Begin forwarded message:

From: = Ray Pelletier <rpelletier@isoc.org>
Subject: = Fwd: (Forward to = others) WebEx meeting invitation: Tools Cmte
Date: = February 14, 2017 at 12:56:41 = PM EST
To: = IETF Tools Development <tools-development@ietf.org>



Begin forwarded message:

From: Ray Pelletier <messenger@webex.com>
Subject: (Forward to others) WebEx meeting invitation: Tools = Cmte
Date: February 10, 2017 at 8:50:29 AM EST
To: <rpelletier@isoc.org>
Reply-To: <rpelletier@isoc.org>

You can forward this invitation to = others.
Hello,
Ray Pelletier invites you to join this WebEx = meeting.
 
Tools = Cmte
Tuesday, February 14, 2017
1:00 pm  |  Eastern Standard Time (New = York, GMT-05:00)  |  1 hr 15 = mins
Meeting number (access code): 821 720 = 794
 
Add = to Calendar
When it's time, join = the = meeting.
 
Join by phone
1-877-668-4490 Call-in toll-free = number (US/Canada)
1-408-792-6300 Call-in toll = number (US/Canada)
Global call-in = numbers  |  Toll-free calling = restrictions
 
Can't join the = meeting?
 
IMPORTANT NOTICE: Please note that this WebEx = service allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the = session.
= --Apple-Mail=_B3F3D493-5015-42A9-9517-5C42C3499C6E Content-Disposition: attachment; filename="WebEx_Meeting.ics" Content-Type: text/calendar; x-unix-mode=0644; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0ABEGIN:VTIMEZONE=0A= TZID:Eastern=20Time=0ABEGIN:STANDARD=0ADTSTART:20151101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0ATZOFFSETTO:-0500=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20150301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0ATZOFFSETTO:-0400=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0ABEGIN:VEVENT=0AATTENDEE;CN=3D"Ray=20= Pelletier";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:rpelletier@isoc.org=0A= ORGANIZER;CN=3D"Ray=20Pelletier":MAILTO:rpelletier@isoc.org=0A= DTSTART;TZID=3D"Eastern=20Time":20170214T130000=0ADTEND;TZID=3D"Eastern=20= Time":20170214T141500=0ALOCATION:https://workgreen.webex.com/workgreen=0A= TRANSP:OPAQUE=0ASEQUENCE:1486734629=0A= UID:709d153f-56bb-4829-9d66-20860ce32fcd=0ADTSTAMP:20170214T180000Z=0A= DESCRIPTION:\n\n\nJOIN=20WEBEX=20= MEETING\nhttps://workgreen.webex.com/workgreen/j.php?MTID=3Dm8dee4f16be754= eec5ea1acbb6af6c36d\nMeeting=20number=20(access=20code):=20821=20720=20= 794\n\n\nJOIN=20BY=20PHONE\n1-877-668-4490=20Call-in=20toll-free=20= number=20(US/Canada)=20\n1-408-792-6300=20Call-in=20toll=20number=20= (US/Canada)\n\nGlobal=20call-in=20= numbers:\nhttps://workgreen.webex.com/workgreen/globalcallin.php?serviceTy= pe=3DMC&ED=3D359850237&tollFree=3D1\n\nToll-free=20dialing=20= restrictions:=20= \nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't=20= join=20the=20meeting?\nhttps://help.webex.com/docs/DOC-5412\n\nIMPORTANT=20= NOTICE:=20Please=20note=20that=20this=20WebEx=20service=20allows=20audio=20= and=20other=20information=20sent=20during=20the=20session=20to=20be=20= recorded,=20which=20may=20be=20discoverable=20in=20a=20legal=20matter.=20= By=20joining=20this=20session,=20you=20automatically=20consent=20to=20= such=20recordings.=20If=20you=20do=20not=20consent=20to=20being=20= recorded,=20discuss=20your=20concerns=20with=20the=20host=20or=20do=20= not=20join=20the=20session.\n=0AX-ALT-DESC;FMTTYPE=3Dtext/html:=09 
 
 
=09=09Join=20WebEx=20meeting=09=09=09=09=09=09= =09=09=09=09=09=09=09=09=09=09=09=09=09=
=09=09=09=09=09=09Meeting=20number=20(access=20code):=20= 821=20720=20794=09=09=09=09=09
=09=09=09=09=09=09=09=09 
 
Join=20by=20phone =20
1-877-668-4490 Call-in=20toll-free=20number=20= (US/Canada) =20
1-408-792-6300 Call-in=20toll=20= number=20(US/Canada) =20
Global=20call-in=20numbers  |  Toll-free=20calling=20= restrictions=20 =20

=09 
=09=09Can't=20join=20the=20= meeting?=09 
 
IMPORTANT=20NOTICE:=20Please=20note=20that=20= this=20WebEx=20service=20allows=20audio=20and=20other=20information=20= sent=20during=20the=20session=20to=20be=20recorded,=20which=20may=20be=20= discoverable=20in=20a=20legal=20matter.=20By=20joining=20this=20session,=20= you=20automatically=20consent=20to=20such=20recordings.=20If=20you=20do=20= not=20consent=20to=20being=20recorded,=20discuss=20your=20concerns=20= with=20the=20host=20or=20do=20not=20join=20the=20session.=0A= SUMMARY:Tools=20Cmte=0APRIORITY:5=0ACLASS:PUBLIC=0ABEGIN:VALARM=0A= TRIGGER:-PT5M=0AACTION:DISPLAY=0ADESCRIPTION:Reminder=0AEND:VALARM=0A= END:VEVENT=0AEND:VCALENDAR=0A= --Apple-Mail=_B3F3D493-5015-42A9-9517-5C42C3499C6E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii"


--Apple-Mail=_B3F3D493-5015-42A9-9517-5C42C3499C6E-- --Apple-Mail=_68AE6AEF-96B4-4478-9105-FAF2D4AAACF9-- From nobody Mon Feb 20 23:09:30 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52679129881 for ; Mon, 20 Feb 2017 23:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlPpugI-51So for ; Mon, 20 Feb 2017 23:09:25 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721A012986D for ; Mon, 20 Feb 2017 23:09:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 47CBA1E569A for ; Mon, 20 Feb 2017 23:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8KH-Ji7vuav for ; Mon, 20 Feb 2017 23:08:18 -0800 (PST) Received: from Heathers-MacBook-Pro.local (unknown [149.154.153.229]) by c8a.amsl.com (Postfix) with ESMTPSA id 988EC1E5698 for ; Mon, 20 Feb 2017 23:08:17 -0800 (PST) References: To: tools-development@ietf.org From: "Heather Flanagan (RFC Series Editor)" X-Forwarded-Message-Id: Message-ID: <88c4ab16-4741-115f-5f43-ed75c62169b1@rfc-editor.org> Date: Tue, 21 Feb 2017 08:09:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------2959E0C7DDD84B298EE192B9" Archived-At: Subject: [TOOLS-DEVELOPMENT] Fwd: [rfc-i] Update on the CSS - second round X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 07:09:28 -0000 This is a multi-part message in MIME format. --------------2959E0C7DDD84B298EE192B9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit In case you are not subscribed to rfc-interest... -------- Forwarded Message -------- Subject: [rfc-i] Update on the CSS - second round Date: Tue, 21 Feb 2017 07:52:12 +0100 From: Heather Flanagan (RFC Series Editor) To: rfc-interest@rfc-editor.org Hello all, Back in December, you all had an opportunity to review the first draft of the CSS that will be applied to the HTML RFCs that will be produced by the RFC Editor when the new formats go live. Issues were collected in github, either by individuals who posted directly, or by me as I harvested issues out of various email threads. You can see the issues here: https://github.com/rfc-format/draft-iab-rfc-css-bis/issues Based on the issues collected (with some decisions from me where we had contradictory input) the CSS developer has built a second version of the CSS. You can see the new look here: https://rfc-format.github.io/draft-iab-rfc-css-bis/ One of the basic changes includes the addition of a very simple JavaScript was added to allow for a hamburger menu to appear when the screen is resized such that the ToC disappears. This JavaScript is not critical to the reading of the text, and so would be allowed. For the issues in github, the following actions were (or were not) taken: * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/17 o [DONE - set table p to margin 0] o Too much v-space in tables o NOTE: Seems like significant over-selection; would be better to select on a class. * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/16 o [DONE - fixed the lists] o Levels of indentations for lists from headings * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/15 o [WON'T DO - See #10] o Increase body indent from headings * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/10 o [DONE - indentation removed] o Don’t have body indent from headings o NOTE: is in contradiction to #15 * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/8 o [DONE] o Padding on aside too large (particularly vertically) o FIXED: remove most padding from aside. * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/7 o [NO CHANGE - kept as is, allowing columns for the Index section except on small devices] o Index in columns o NOTE: glad that this appears to be supported. I would like to keep columns. * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/6 o [DONE *- *fixed monospace font sizes] o Heading with a monospace item in it * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/4 o [DONE for small devices where the menu will hang over the page content; wide widths have no divider (to remain uncluttered)]** o Visual separation between draft and TOC * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/3 o [NO CHANGE - prefer the margin + border to ensure blockquote stands out] o Frame + border seems too much for blockquote * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/2 o [NO CHANGE - paragraph spacing easier to see using real examples of sample2.html and sample3.html - we should wait for feedback on this now that the community can see what the paragraph spacing looks like in practice] o Paragraph spacing too large * https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/1 o [DONE - headings decreased in size both in desktop and mobile versions] o Headings too large Please take a moment to look at the slightly updated design, and to post your feedback either to this list or directly to github. I’m expecting the third (and final, for now) set of changes to focus on polishing the details of the look and feel. Thank you for your time and attention! -- Heather Flanagan --------------2959E0C7DDD84B298EE192B9 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcmZjLWlu dGVyZXN0IG1haWxpbmcgbGlzdApyZmMtaW50ZXJlc3RAcmZjLWVkaXRvci5vcmcKaHR0cHM6 Ly93d3cucmZjLWVkaXRvci5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmMtaW50ZXJlc3QKCg== --------------2959E0C7DDD84B298EE192B9-- From nobody Tue Feb 21 03:39:22 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EF51298BC for ; Tue, 21 Feb 2017 03:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RChyXelWB-J5 for ; Tue, 21 Feb 2017 03:39:20 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A45912965B for ; Tue, 21 Feb 2017 03:39:20 -0800 (PST) Received: from [2001:6b0:7:0:880:4000:2c5c:ec41] (port=64325 helo=tannat.pilsnet.sunet.se) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cg8mr-0000ge-Lf; Tue, 21 Feb 2017 03:39:18 -0800 To: "Heather Flanagan (RFC Series Editor)" , tools-development@ietf.org References: <88c4ab16-4741-115f-5f43-ed75c62169b1@rfc-editor.org> From: Henrik Levkowetz Message-ID: <58AC26E0.6070801@levkowetz.com> Date: Tue, 21 Feb 2017 12:39:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <88c4ab16-4741-115f-5f43-ed75c62169b1@rfc-editor.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:6b0:7:0:880:4000:2c5c:ec41 X-SA-Exim-Rcpt-To: tools-development@ietf.org, rse@rfc-editor.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fwd: [rfc-i] Update on the CSS - second round X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 11:39:21 -0000 Hi Heather, On 2017-02-21 08:09, Heather Flanagan (RFC Series Editor) wrote: > In case you are not subscribed to rfc-interest... I am, but that subscription goes to a folder, and I don't necessarily see what's arriving regularly. So thank you :-) Henrik > -------- Forwarded Message -------- > Subject: [rfc-i] Update on the CSS - second round > Date: Tue, 21 Feb 2017 07:52:12 +0100 > From: Heather Flanagan (RFC Series Editor) > To: rfc-interest@rfc-editor.org > > > > Hello all, > > Back in December, you all had an opportunity to review the first draft > of the CSS that will be applied to the HTML RFCs that will be produced > by the RFC Editor when the new formats go live. Issues were collected in > github, either by individuals who posted directly, or by me as I > harvested issues out of various email threads. You can see the issues here: > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues > > Based on the issues collected (with some decisions from me where we had > contradictory input) the CSS developer has built a second version of the > CSS. You can see the new look here: > > https://rfc-format.github.io/draft-iab-rfc-css-bis/ > > One of the basic changes includes the addition of a very simple > JavaScript was added to allow for a hamburger menu to appear when the > screen is resized such that the ToC disappears. This JavaScript is not > critical to the reading of the text, and so would be allowed. > For the issues in github, the following actions were (or were not) taken: > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/17 > > o > > [DONE - set table p to margin 0] > > o > > Too much v-space in tables > > o > > NOTE: Seems like significant over-selection; would be better to > select on a class. > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/16 > > o > > [DONE - fixed the lists] > > o > > Levels of indentations for lists from headings > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/15 > > o > > [WON'T DO - See #10] > > o > > Increase body indent from headings > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/10 > > o > > [DONE - indentation removed] > > o > > Don’t have body indent from headings > > o > > NOTE: is in contradiction to #15 > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/8 > > o > > [DONE] > > o > > Padding on aside too large (particularly vertically) > > o > > FIXED: remove most padding from aside. > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/7 > > o > > [NO CHANGE - kept as is, allowing columns for the Index section > except on small devices] > > o > > Index in columns > > o > > NOTE: glad that this appears to be supported. I would like to > keep columns. > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/6 > > o [DONE *- *fixed monospace font sizes] > > o > > Heading with a monospace item in it > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/4 > > o [DONE for small devices where the menu will hang over the page > content; wide widths have no divider (to remain uncluttered)]** > > o > > Visual separation between draft and TOC > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/3 > > o [NO CHANGE - prefer the margin + border to ensure blockquote > stands out] > > o > > Frame + border seems too much for blockquote > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/2 > > o [NO CHANGE - paragraph spacing easier to see using real examples > of sample2.html and sample3.html - we should wait for feedback > on this now that the community can see what the paragraph > spacing looks like in practice] > > o > > Paragraph spacing too large > > * > > https://github.com/rfc-format/draft-iab-rfc-css-bis/issues/1 > > o > > [DONE - headings decreased in size both in desktop and mobile > versions] > > o > > Headings too large > > > > Please take a moment to look at the slightly updated design, and to post > your feedback either to this list or directly to github. I’m expecting > the third (and final, for now) set of changes to focus on polishing the > details of the look and feel. > > Thank you for your time and attention! > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > From nobody Fri Feb 24 09:57:27 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5311129458 for ; Fri, 24 Feb 2017 09:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbuEmWwZGJep for ; Fri, 24 Feb 2017 09:57:24 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEBB12944D for ; Fri, 24 Feb 2017 09:57:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 764BE300426 for ; Fri, 24 Feb 2017 12:57:23 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tauim4OO7QW4 for ; Fri, 24 Feb 2017 12:57:22 -0500 (EST) Received: from [192.168.2.107] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A0C3F30024F for ; Fri, 24 Feb 2017 12:57:22 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <81EE085C-372A-4976-A53E-0C1EF39C409E@vigilsec.com> Date: Fri, 24 Feb 2017 12:57:24 -0500 To: IETF Tools Development X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [TOOLS-DEVELOPMENT] Website Revamp Program Manager X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:57:25 -0000 Joe Hildebrand has asked to be replaced as Website Revamp Program = Manager. He does not have time for this role with his new job. I had a conversation with Joe, and he thinks that the project has = advanced to the point that no applications layer expertise is needed. = Only program management skills are needed to drive this to completion. = So, I am going to take on the role of Website Revamp Program Manager = myself. My expectation is that this project will be completed in the = next few weeks. Russ From nobody Sat Feb 25 09:51:30 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639A412A1E7 for ; Sat, 25 Feb 2017 09:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=cursive.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df6B3J3LvXRM for ; Sat, 25 Feb 2017 09:51:28 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22749129454 for ; Sat, 25 Feb 2017 09:51:28 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id h10so40617817ith.1 for ; Sat, 25 Feb 2017 09:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cursive.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3jNuXAYUXXvNA1WKxfibH4ux/wJa2RuMdCZ6fs80gOk=; b=pVfBvXGf7B2hUq9+WQMC3cYKopgX/JYqHlhJquYWYbWk10aXz3LCckT8H/ELMOv6QK Ap8r48Y/01OJx1GMXr+6o3hg1WYzICwNuwWyIGBWRHlGr1seUHObupSNbpjw8RcUHtmG ZBAU8LF84CRCUCqWafFFXwNrKAoAervpyjiN0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3jNuXAYUXXvNA1WKxfibH4ux/wJa2RuMdCZ6fs80gOk=; b=KKzQWEGjd0Udm1kwEYYEOmcMncTeIRP7W3OSkfNxCPVtE4JiLEQRtYtuUDDVc083MZ CcL3MCuzKzvOJRXkMvuHiDxHjoCrspza9wyLERdcVdcJWa1sPsVXpMoCxeVYhWocYent KCOjyyivepoj6fuHdTeIpU0ViKNdBZVO+QL0Ap7Odxy1nTDfkyg96mBfXZ2l06yCPrXS zNyRr1QPX6vMjYK8n689eWmlpvix7Gu4whRiCkKCpqGTsQGu8/t8I7HlOCpcLq0uOhUD 1g252G/tui6aRl3JqTVI+hwXNYoPnzEsj1wWEJWunp2TqwpxdY2zJMZcmu5Zm2sNjCMG St9w== X-Gm-Message-State: AMke39mViw+cXpMhyngsn1O0GLVE1kF3uPk0zLxcL4X9GBuYri/PfwvTeV+e1J3gV0qWzw== X-Received: by 10.36.181.2 with SMTP id v2mr8357371ite.45.1488045087294; Sat, 25 Feb 2017 09:51:27 -0800 (PST) Received: from ?IPv6:2601:282:200:9150:a484:7304:fa59:645f? ([2601:282:200:9150:a484:7304:fa59:645f]) by smtp.gmail.com with ESMTPSA id i189sm2226146ita.23.2017.02.25.09.51.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Feb 2017 09:51:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Joe Hildebrand In-Reply-To: <81EE085C-372A-4976-A53E-0C1EF39C409E@vigilsec.com> Date: Sat, 25 Feb 2017 10:51:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81EE085C-372A-4976-A53E-0C1EF39C409E@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] Website Revamp Program Manager X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 17:51:29 -0000 Thanks, Russ, for volunteering to finish this off. > On Feb 24, 2017, at 10:57 AM, Russ Housley = wrote: >=20 >=20 > Joe Hildebrand has asked to be replaced as Website Revamp Program = Manager. He does not have time for this role with his new job. >=20 > I had a conversation with Joe, and he thinks that the project has = advanced to the point that no applications layer expertise is needed. = Only program management skills are needed to drive this to completion. = So, I am going to take on the role of Website Revamp Program Manager = myself. My expectation is that this project will be completed in the = next few weeks. >=20 > Russ >=20 >=20 >=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development =E2=80=94=20 Joe Hildebrand From nobody Mon Feb 27 12:56:23 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A934C128874 for ; Mon, 27 Feb 2017 12:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys_Q7H39kcmB for ; Mon, 27 Feb 2017 12:56:06 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2681A12A33D for ; Mon, 27 Feb 2017 12:56:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C662B1E5681; Mon, 27 Feb 2017 12:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQum51M1pdos; Mon, 27 Feb 2017 12:55:58 -0800 (PST) Received: from Heathers-MacBook-Pro.local (c-50-159-75-65.hsd1.wa.comcast.net [50.159.75.65]) by c8a.amsl.com (Postfix) with ESMTPSA id 7D8861E567B; Mon, 27 Feb 2017 12:55:58 -0800 (PST) References: To: rsoc@iab.org, iab@iab.org, tools-development@ietf.org From: "Heather Flanagan (RFC Series Editor)" X-Forwarded-Message-Id: Message-ID: <807baf37-6c21-ae9f-07ee-b6e89d3931c3@rfc-editor.org> Date: Mon, 27 Feb 2017 12:56:04 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------84B7190B2A31F6EEE99E94A7" Archived-At: Subject: [TOOLS-DEVELOPMENT] Fwd: Fwd: [rfc-i] RFC Server Maintenance Outage March 6th X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 20:56:10 -0000 This is a multi-part message in MIME format. --------------84B7190B2A31F6EEE99E94A7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello RSOC, IAB, Tools, In case you are not on rfc-interest (or file it off to a separate folder somewhere), this is an FYI that there will be RFC Editor server maintenance taking place next Monday. See the email below for more details. Please let me know if you have any questions, Heather > Begin forwarded message: > > *From: *Glen > > *Subject: **[rfc-i] RFC Server Maintenance Outage March 6th* > *Date: *February 27, 2017 at 8:33:44 AM PST > *To: *rfc-interest@rfc-editor.org > *Reply-To: *glen@amsl.com > > All -- > > On Monday, March 6th, we will be having a pre-planned maintenance > outage on the RFC Editor server group. The maintenance window - the > period during which outages may occur - is expected to be from > 1600-2000 GMT on that day. > > During the outage window, access to web, email, and related RFC-Editor > sites and services will be impacted, and some services will be > unavailable for brief periods. Services may be unavailable at > different intervals, and the availability of one service with the > simultaneous unavailability of another service should not be a cause > for alarm. > > These maintenance windows are necessary to perform operating system > and related software upgrades on the servers supporting the > RFC-Editor. > > Thank you for your patience with this process. > > Glen > -- > Glen Barney > IT Director > AMS (RFC-Editor Secretariat) > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest > --------------84B7190B2A31F6EEE99E94A7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello RSOC, IAB, Tools,

In case you are not on rfc-interest (or file it off to a separate folder somewhere), this is an FYI that there will be RFC Editor server maintenance taking place next Monday. See the email below for more details.

Please let me know if you have any questions,

Heather


Begin forwarded message:

From: Glen <glen@amsl.com>
Subject: [rfc-i] RFC Server Maintenance Outage March 6th
Date: February 27, 2017 at 8:33:44 AM PST
Reply-To: glen@amsl.com

All --

On Monday, March 6th, we will be having a pre-planned maintenance
outage on the RFC Editor server group.  The maintenance window - the
period during which outages may occur - is expected to be from
1600-2000 GMT on that day.

During the outage window, access to web, email, and related RFC-Editor
sites and services will be impacted, and some services will be
unavailable for brief periods.  Services may be unavailable at
different intervals, and the availability of one service with the
simultaneous unavailability of another service should not be a cause
for alarm.

These maintenance windows are necessary to perform operating system
and related software upgrades on the servers supporting the
RFC-Editor.

Thank you for your patience with this process.

Glen
--
Glen Barney
IT Director
AMS (RFC-Editor Secretariat)
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest


--------------84B7190B2A31F6EEE99E94A7--