From nobody Mon Mar 9 14:52:29 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3827B1AC3B6 for ; Mon, 9 Mar 2015 14:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOlBCb_iu6bm for ; Mon, 9 Mar 2015 14:52:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EAE1A0196 for ; Mon, 9 Mar 2015 14:52:26 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t29LqP7R050741 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Mar 2015 16:52:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <54FE1614.5080009@nostrum.com> Date: Mon, 09 Mar 2015 16:52:20 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tools Team Discussion Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Tools-discuss] For tomorrows call: Email handling in the datatracker X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:52:28 -0000 All - As I hope you've seen on ietf@ietf.org, there is some pain around how email is currently being sent through the aliases and from the tracker. Here is some background for discussion tomorrow. Please read through this before we get to the meeting. Henrik and I have both been studying this, and have several steps we are going to take right away. I've also been discussing how draft ballot email is handled with Pete to prepare a proposal for the IESG to agree on. I will send a separate message with more detail than you want (but you need it) about where the tracker is sending mail right now. In short, we have these factors primarily contributing to the pain: 1) In November, we started adding the working group list to the .notify alias by default at the request of the IESG. This was driven by the IESG wanting the group to see ballot positions, and make it likely that responses to those positions would be in-thread. 2) Shortly after, we started migrating to @ietf.org aliases instead of tools.ietf.org alias. 3) 10-11 days ago (depending on when you read this message), we started forwarding the aliases @tools.ietf.org to use the aliases at @ietf.org instead of expanding them on the tools server. Now, there were several things related to those 3 changes that have rough edges: a) Adding the working group list to .notify had an unintended consequence. What we didn't account for is that the contents of .notify get expanded into the .all alias, so people sending mail to .all for some draft end up sending to the list. b) When tools.ietf.org was expanding aliases, it added Resent-To and Resent-From headers. The expansion at ietf.org does not currently do that, and we are working to fix it. Some people were filtering on these headers. It's also likely (we haven't confirmed this yet) that Mailman was using the headers to bypass putting mail to .all into moderation for having an implicit destination. c) The aliases at ietf.org are _NOT THE SAME_ as the aliases at tools.ietf.org! The datatracker allows addresses to be marked active or inactive. If an address that's in a draft is marked inactive, then the ietf.org alias will not use it - it will find the most recently changed active address for that person instead and use that. The tools.ietf.org aliases are not aware of these bits, and used the address in the draft always. Further, when addresses are learned from drafts by the submit tool, with the currently deployed code, they are marked inactive (the idea at the time was that we didn't want mail to start going to a different address for a person each time they submitted a draft using a different email address - several years ago we had a big problem with people being surprised by such automatic changes. Instead, they could activate each address they wanted the tracker to use.) So, we are making the following changes right away: Now - i) We are teaching the tracker about a "preferred" address to use whenever context doesn't indicate a better choice (often context will say to use the address attached to a chair role for instance). The address the tracker is preferring now (specifically the last active address that's been touched) will be marked "preferred". Now - ii) We are marking the addresses that are in drafts that are current as active. If someone with an account has an addresses active state changed by this, we will send mail to the affected address and all other active addresses for them letting them know it happened (in case they really _wanted_ that address to be inactive). As new drafts go through the submit tool, any learned addresses will be marked active (but note that the "preferred" address will not be automatically changed). After that release, most of the addressing that has been surprising people in the last 10 days will be resolved. The ietf.org aliases will much more closely match what had been being generated at tools.ietf.org. We (primarily Glen and Matt) are also continuing to work on getting Resent-To and Resent-From into mail forwarded through the aliases at ietf.org. We should set the priority for this on tomorrows call (I suggest it that it's priority should be high). Now, early discussions with Pete and Henrik lead to this rough proposal that will be sent to the IESG. This is a draft idea, and we won't execute on it until the IESG says to (Pete, note this is slightly different than what we discussed last). I expect the discussion with the IESG to change this some. Soon - i) The "Save and Send Email" page in the ballot editing workflow currently offers the content of the .notify field with a checkbox (selected by default). We plan to add another row, with the group's list address, also with a checkbox selected by default. If the AD sending the message doesn't want the list copied, they unselect the box next to the list address. (We might, instead, have to turn this into a bit that lives on the document that the sponsoring AD manages, making it their choice rather than the balloting ADs choice). Soon - ii) We will scrub all the documents and remove the list address from the .notify field. We'll send notes to the document personnel of each affected document so they can verify that the result is what they want. Soon - iii) We'll add a .group alias for people to use to copy the WG list for a draft without having to look it up. The contents of this alias would not be included when sending to .all Sorry for the long message, but there's a lot involved here. Hopefully I've teased it apart into easier to follow chunks. Talk to you all tomorrow, RjS From nobody Mon Mar 9 15:10:42 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196D61A0161 for ; Mon, 9 Mar 2015 15:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOcTfW5Wl-qp for ; Mon, 9 Mar 2015 15:10:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080CD1AC3A2 for ; Mon, 9 Mar 2015 15:10:39 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t29MAc4H052306 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Mar 2015 17:10:38 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <54FE1A59.3060708@nostrum.com> Date: Mon, 09 Mar 2015 17:10:33 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tools-discuss@ietf.org References: <54FE181E.7060201@nostrum.com> In-Reply-To: <54FE181E.7060201@nostrum.com> X-Forwarded-Message-Id: <54FE181E.7060201@nostrum.com> Content-Type: multipart/alternative; boundary="------------070909050205080205040708" Archived-At: Subject: [Tools-discuss] Fwd: Details about where the tracker is currently sending mail X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:10:41 -0000 This is a multi-part message in MIME format. --------------070909050205080205040708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hrmm - that went into moderation. The attachments are also at http://www.nostrum.com/~rjsparks/email-analysis.xlsx and http://www.nostrum.com/~rjsparks/email-analysis.pdf Moderator - feel free to nuke the original message -------- Forwarded Message -------- Subject: Details about where the tracker is currently sending mail Date: Mon, 09 Mar 2015 17:01:02 -0500 From: Robert Sparks To: Tools-discuss@ietf.org All - The attached spreadsheet (and a pdf printout from it) summarize when mail comes out of the tracker and who that mail goes to. The solid dots in the matrix mean mail is always sent. The open dot means mail is conditionally sent (and the condition is explained in the notes). There is one row (about ballots) that has a checkbox symbol - that means the AD can select or unselect that destination (an alias in this case), before sending. The notes call out the other places that the sender has an opportunity to change the destinations before the message is sent. I took one shortcut that doesn't align with the above to make the chart less messy. When you see solid dots for group chairs and shepherds, know that if a document has no group, or no shepherd has been assigned, then those destinations aren't used. I also haven't included a few messages that the tracker sends. Specifically, I didn't list the messages related to the community tracker (subscribing to changes for a draft and getting the mail for those changes). The destination addresses there are always the person subscribing. I didn't include the messages that are sent only to the secretariat by robots (such as the iana sync report, the rfc-editor queue message, or when the tracker lets the secretariat know that a message tried to go out with a bad email address in it). I didn't include the messages sent to verify email when setting up a datatracker account. If you're interested, you can see a code-oriented view that _does_ include all those cases at . If you see something in the spreadsheet or in the web page above that you don't think is right, ask me. This was a brutal compilation effort - the odds that I didn't get something wrong are small. RjS --------------070909050205080205040708 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hrmm - that went into moderation.
The attachments are also at
http://www.nostrum.com/~rjsparks/email-analysis.xlsx
and
http://www.nostrum.com/~rjsparks/email-analysis.pdf

Moderator - feel free to nuke the original message


-------- Forwarded Message --------
Subject: Details about where the tracker is currently sending mail
Date: Mon, 09 Mar 2015 17:01:02 -0500
From: Robert Sparks <rjsparks@nostrum.com>
To: Tools-discuss@ietf.org 


All -

The attached spreadsheet (and a pdf printout from it) summarize when 
mail comes out of the tracker and who that mail goes to.

The solid dots in the matrix mean mail is always sent.
The open dot means mail is conditionally sent (and the condition is 
explained in the notes).
There is one row (about ballots) that has a checkbox symbol - that means 
the AD can select or unselect that destination (an alias in this case), 
before sending.
The notes call out the other places that the sender has an opportunity 
to change the destinations before the message is sent.

I took one shortcut that doesn't align with the above to make the chart 
less messy. When you see solid dots for group chairs and shepherds, know 
that if a document has no group, or no shepherd has been assigned, then 
those destinations aren't used.

I also haven't included a few messages that the tracker sends.

Specifically, I didn't list the messages related to the community 
tracker (subscribing to changes for a draft and getting the mail for 
those changes). The destination addresses there are always the person 
subscribing.

I didn't include the messages that are sent only to the secretariat by 
robots (such as the iana sync report, the rfc-editor queue message, or 
when the tracker lets the secretariat know that a message tried to go 
out with a bad email address in it).

I didn't include the messages sent to verify email when setting up a 
datatracker account.

If you're interested, you can see a code-oriented view that _does_ 
include all those cases at
<http://www.nostrum.com/~rjsparks/email-analysis/>.

If you see something in the spreadsheet or in the web page above that 
you don't think is right, ask me. This was a brutal compilation effort - 
the odds that I didn't get something wrong are small.

RjS


--------------070909050205080205040708-- From nobody Mon Mar 9 15:21:12 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3E61ACDE4 for ; Mon, 9 Mar 2015 15:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KG6wH9lD_Bpx for ; Mon, 9 Mar 2015 15:20:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6291AC3D5 for ; Mon, 9 Mar 2015 15:20:39 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t29MKduF053134 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Mar 2015 17:20:39 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <54FE1CB2.3020605@nostrum.com> Date: Mon, 09 Mar 2015 17:20:34 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tools Team Discussion References: <54FE1614.5080009@nostrum.com> In-Reply-To: <54FE1614.5080009@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] For tomorrows call: Email handling in the datatracker X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:21:03 -0000 Pete pointed out that I missed one thing in the contributing factors that has already been changed. See inline below. On 3/9/15 4:52 PM, Robert Sparks wrote: > All - > > As I hope you've seen on ietf@ietf.org, there is some pain around how > email is currently being sent through the aliases and from the tracker. > Here is some background for discussion tomorrow. Please read through > this before we get to the meeting. > > Henrik and I have both been studying this, and have several steps we > are going to take right away. I've also been discussing how draft > ballot email is handled with Pete to prepare a proposal for the IESG > to agree on. > > I will send a separate message with more detail than you want (but you > need it) about where the tracker is sending mail right now. > > In short, we have these factors primarily contributing to the pain: > > 1) In November, we started adding the working group list to the > .notify alias by default at the request of the IESG. This was driven > by the IESG wanting the group to see ballot positions, and make it > likely that responses to those positions would be in-thread. In November, when we made that change, we also included the .all alias in the default for .notify. That was a lazy way of saying "Get the chairs and the shepherd, etc.", and it introduced an expansion loop (since .all has all of .notify in its extension) In a release in early February (IIRC) the default changed to using the constituent components instead, and there was work in the alias handling system to not break when loops happened. But we have a few drafts out there that still have .all in their .notify field. > > 2) Shortly after, we started migrating to @ietf.org aliases instead of > tools.ietf.org alias. > > 3) 10-11 days ago (depending on when you read this message), we > started forwarding the aliases @tools.ietf.org to use the aliases at > @ietf.org instead of expanding them on the tools server. > > Now, there were several things related to those 3 changes that have > rough edges: > > a) Adding the working group list to .notify had an unintended > consequence. What we didn't account for is that the contents of > .notify get expanded into the .all alias, so people sending mail to > .all for some draft end up sending to the list. > > b) When tools.ietf.org was expanding aliases, it added Resent-To and > Resent-From headers. The expansion at ietf.org does not currently do > that, and we are working to fix it. Some people were filtering on > these headers. It's also likely (we haven't confirmed this yet) that > Mailman was using the headers to bypass putting mail to .all into > moderation for having an implicit destination. > > c) The aliases at ietf.org are _NOT THE SAME_ as the aliases at > tools.ietf.org! The datatracker allows addresses to be marked active > or inactive. If an address that's in a draft is marked inactive, then > the ietf.org alias will not use it - it will find the most recently > changed active address for that person instead and use that. The > tools.ietf.org aliases are not aware of these bits, and used the > address in the draft always. Further, when addresses are learned from > drafts by the submit tool, with the currently deployed code, they are > marked inactive (the idea at the time was that we didn't want mail to > start going to a different address for a person each time they > submitted a draft using a different email address - several years ago > we had a big problem with people being surprised by such automatic > changes. Instead, they could activate each address they wanted the > tracker to use.) > > So, we are making the following changes right away: > > Now - i) We are teaching the tracker about a "preferred" address to > use whenever context doesn't indicate a better choice (often context > will say to use the address attached to a chair role for instance). > The address the tracker is preferring now (specifically the last > active address that's been touched) will be marked "preferred". > > Now - ii) We are marking the addresses that are in drafts that are > current as active. If someone with an account has an addresses active > state changed by this, we will send mail to the affected address and > all other active addresses for them letting them know it happened (in > case they really _wanted_ that address to be inactive). As new drafts > go through the submit tool, any learned addresses will be marked > active (but note that the "preferred" address will not be > automatically changed). > > After that release, most of the addressing that has been surprising > people in the last 10 days will be resolved. The ietf.org aliases will > much more closely match what had been being generated at tools.ietf.org. > > We (primarily Glen and Matt) are also continuing to work on getting > Resent-To and Resent-From into mail forwarded through the aliases at > ietf.org. We should set the priority for this on tomorrows call (I > suggest it that it's priority should be high). > > Now, early discussions with Pete and Henrik lead to this rough > proposal that will be sent to the IESG. This is a draft idea, and we > won't execute on it until the IESG says to (Pete, note this is > slightly different than what we discussed last). I expect the > discussion with the IESG to change this some. > > Soon - i) The "Save and Send Email" page in the ballot editing > workflow currently offers the content of the .notify field with a > checkbox (selected by default). We plan to add another row, with the > group's list address, also with a checkbox selected by default. If the > AD sending the message doesn't want the list copied, they unselect the > box next to the list address. (We might, instead, have to turn this > into a bit that lives on the document that the sponsoring AD manages, > making it their choice rather than the balloting ADs choice). > > Soon - ii) We will scrub all the documents and remove the list address > from the .notify field. We'll send notes to the document personnel of > each affected document so they can verify that the result is what they > want. > > Soon - iii) We'll add a .group alias for people to use to copy the WG > list for a draft without having to look it up. The contents of this > alias would not be included when sending to .all > > Sorry for the long message, but there's a lot involved here. Hopefully > I've teased it apart into easier to follow chunks. > > Talk to you all tomorrow, > > RjS > > > > From nobody Tue Mar 10 15:20:24 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9991A8F43 for ; Tue, 10 Mar 2015 15:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlKiM-OVlefW for ; Tue, 10 Mar 2015 15:20:21 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D87F1A9040 for ; Tue, 10 Mar 2015 15:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1540; q=dns/txt; s=iport; t=1426026017; x=1427235617; h=from:to:cc:subject:date:message-id:mime-version; bh=1QzOwR9GFdi9SLGJ8LtcbH1EEBOECkFUtBb+HTWx8m4=; b=RM30V9LsLhif1luj7CwU/1jAeMZ2Xd/EoW8xdgh5QTc/8Gd60wUr7fcY Jd+jH/zXgPpHwDJ+0NVahzjd9wTnsMNtDQzh3H4CKh9ACi0r44eitqtfR tUGBcwQO8GFXeHG7xYJiLTJnHJOtCVByt+LK+7QKxBZchvWLGeX8WU5Oc g=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQCsbf9U/4sNJK1cgwaBMIMGxheBNU0BAQEBAQF8hBYjSwkCEgEWNAI0HwgEDhOIIapbm0MBAQEBAQEBAQEBAQEBAQEBAQEBGY8jEQFQgm8vgRYFkBmBZYEuhkiTdyODboF6OX8BAQE X-IronPort-AV: E=Sophos;i="5.11,377,1422921600"; d="asc'?scan'208";a="402478409" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP; 10 Mar 2015 22:20:16 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2AMKF17015708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 22:20:15 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 17:20:15 -0500 From: "Fred Baker (fred)" To: Ray Pelletier Thread-Topic: internet draft notifications Thread-Index: AQHQW4BhtBqyng2KhU2kqkF+T8jYfQ== Date: Tue, 10 Mar 2015 22:20:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.61.251] Content-Type: multipart/signed; boundary="Apple-Mail=_B36C2599-7F95-4F5D-B1F5-5D09B3CCBB97"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tools-discuss@ietf.org" Subject: [Tools-discuss] internet draft notifications X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 22:20:22 -0000 --Apple-Mail=_B36C2599-7F95-4F5D-B1F5-5D09B3CCBB97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I imagine you are seeing the thread on ietf@ about draft announcements. = Here=E2=80=99s a thought. What if some tool at AMS, instead of instantly posting an email saying = =E2=80=9Cwe got another draft=E2=80=9D, added the name and abstract of = the draft to some file somewhere associated with a mailing list (ietf@, = work group list, or whatever else), and at the end of the day (by some = definition - 5:00 PM on the east side of the date line perhaps) sent all = of the emails, one per list? That would give people the batching effect = they mention... --Apple-Mail=_B36C2599-7F95-4F5D-B1F5-5D09B3CCBB97 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVP9tOJ9ieig10VPpAQIhKgf/RxzFjMvHNEXLbopYcIn6j0CVgM0ULylN fcEHoAotDbNEeQrry0/DXZ7qyRqBdKvPp2d9rk2kohMyJRoZeUwtxie6kcrDi4gZ weZv32y9tC+18ea7xLDZ501AwrhNDLtx6PBbTg02IAQES/feUV0SwT7wgRxsdhuX zqVCnNeuGNLBnlEDTCJGqOQ1S5PjGLb7fOzxFNBKH5N3VRbsB+ASk5rRi6t3+VfE StHwzE2vLvh4Q6fCgcCK+Sk11P1ebmFgsDyDvOBD7fEAHdhKfcqEQwkPGdROD6G8 eA3ttNZClhcYM2GF5lKzqDwAJdiC5qQ/OGxWthFZAt9x9faaoOJ8gQ== =lM4X -----END PGP SIGNATURE----- --Apple-Mail=_B36C2599-7F95-4F5D-B1F5-5D09B3CCBB97-- From nobody Wed Mar 11 07:08:19 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D3E1ACD7E for ; Wed, 11 Mar 2015 07:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfGqe5CXE0gS for ; Wed, 11 Mar 2015 07:08:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC2E1ACD7D for ; Wed, 11 Mar 2015 07:08:13 -0700 (PDT) Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2BE7lgG011026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Mar 2015 07:07:50 -0700 Message-ID: <55004C30.1010606@dcrocker.net> Date: Wed, 11 Mar 2015 07:07:44 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Ray Pelletier References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 11 Mar 2015 07:07:50 -0700 (PDT) Archived-At: Cc: "tools-discuss@ietf.org" Subject: Re: [Tools-discuss] internet draft notifications X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 14:08:15 -0000 On 3/10/2015 3:20 PM, Fred Baker (fred) wrote: > What if some tool at AMS, instead of instantly posting an email saying “we got another draft”, added the name and abstract of the draft to some file somewhere associated with a mailing list (ietf@, work group list, or whatever else), and at the end of the day (by some definition - 5:00 PM on the east side of the date line perhaps) sent all of the emails, one per list? That would give people the batching effect they mention... The premise behind this is that some hours of delay in getting notified is not an issue. For most of us and for most documents, this is no doubt correct. The question is the exceptions. Common mailing list packages allow individual subscribers to distinguish between getting each message as posted, versus a daily aggregation. I believe Fred's proposal is to default to the latter, for announcement of new drafts. ietf-announce is a standard mailman mailing list, which gives the list administrator control over some relevant settings: > Can list members choose to receive list traffic bunched in digests? > (Edit digestable) > > No > Yes > Which delivery mode is the default for new users? > (Edit digest_is_default) > > Regular Digest Moving the default to 'aggregate' would then place the requirement on those wishing individual, immediate copies to change from the default. To get the granularity down to "draft announcements" rather than all announcements will require a separate list. The real challenge is to distinguish between different drafts and handle them differentially. I've no idea how to accomplish that reasonably, with the current tools. d/ From nobody Thu Mar 19 19:04:17 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D92C1A9125 for ; Thu, 19 Mar 2015 18:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.288 X-Spam-Level: X-Spam-Status: No, score=-101.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5uvYWiQZS7I for ; Thu, 19 Mar 2015 18:59:35 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 255831A9129 for ; Thu, 19 Mar 2015 18:59:34 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E37BA1E5D86 for ; Thu, 19 Mar 2015 18:58:48 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by c8a.amsl.com (Postfix) with ESMTPSA id B35941E5D58 for ; Thu, 19 Mar 2015 18:58:48 -0700 (PDT) Received: by qgfa8 with SMTP id a8so82185376qgf.0 for ; Thu, 19 Mar 2015 18:59:33 -0700 (PDT) X-Received: by 10.55.23.71 with SMTP id i68mr152664630qkh.79.1426816772984; Thu, 19 Mar 2015 18:59:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.140.201 with HTTP; Thu, 19 Mar 2015 18:59:12 -0700 (PDT) From: Glen Date: Thu, 19 Mar 2015 18:59:12 -0700 Message-ID: To: Glen Barney Content-Type: multipart/alternative; boundary=001a1147a450e9d8580511aeaa0d Archived-At: X-Mailman-Approved-At: Thu, 19 Mar 2015 19:04:16 -0700 Subject: [Tools-discuss] Glen (AMS IT) in Dallas X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 01:59:36 -0000 --001a1147a450e9d8580511aeaa0d Content-Type: text/plain; charset=UTF-8 Greetings! For those of you who may not know me, I'm Glen Barney, the IT Director at AMS, which is the company that provides secretariat and IT services to the IETF. For those of you who -do- know me, well, sadly, I've missed quite a few meetings, but I'm excited to report that I'm going to be in Dallas for the early part of the meeting next week! One of the main reasons I come to the meetings, when I can, is to make myself available to you, members of the IETF leadership, ADs, Working Group chairs, and volunteers, in the event that you want to talk about anything related to AMS IT stuff. If you have questions, or comments, or suggestions, just want to talk, have a beer, or throw food at me, I absolutely want to talk to you and meet you in Dallas! I may be moving around quite a bit this meeting, but you can easily reach me in any of the following ways: Google Plus: https://plus.google.com/113536982200502888028 (Circle me or send me an email or a hangout at glenams@gmail.com ) Twitter: @glenamstweets (Follow me, DM or send me a @mention) Jabber: glen@amsl.com Email: glen@amsl.com I'll be in Dallas from Saturday morning through Tuesday noon, and, with Matt Larson (also from AMS IT), I will be present and available and hoping to meet as many of you as possible! Thanks! Glen Glen Barney IT Director AMS (IETF Secretariat) --001a1147a450e9d8580511aeaa0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greetings!

For those of you who may not know me, I'm Glen Barney, the IT Dir= ector at AMS, which is the company that provides secretariat and IT service= s to the IETF.

For those of you who -do- know me, w= ell, sadly, I've missed quite a few meetings, but I'm excited to re= port that I'm going to be in Dallas for the early part of the meeting n= ext week!

One of the main reasons I come to the meetings, when= I can, is to make myself available to you, members of the IETF leadership,= ADs, Working Group chairs, and volunteers, in the event that you want to t= alk about anything related to AMS IT stuff.=C2=A0 If you have questions, or= comments, or suggestions, just want to talk, have a beer, or throw food at= me, I absolutely want to talk to you and meet you in Dallas!

=
I may be moving around quite a bit this meeting, but you can easily re= ach me in any of the following ways:

Google Plus:=C2=A0 <= a href=3D"https://plus.google.com/113536982200502888028">https://plus.googl= e.com/113536982200502888028=C2=A0 (Circle me or send me an email or a h= angout at glenams@gmail.com )
<= br>Twitter:=C2=A0 @glenamstweets (Follow me, DM or send me a @mention)
<= br>
Jabber:=C2=A0 glen@amsl.com<= /a>

I'll be in Dallas from Saturday morning t= hrough Tuesday noon, and, with Matt Larson (also from AMS IT), I will be pr= esent and available and hoping to meet as many of you as possible!

<= /div>
Thanks!

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

--001a1147a450e9d8580511aeaa0d-- From nobody Sun Mar 22 09:34:03 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4801AC3D6 for ; Sun, 22 Mar 2015 09:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whtWrlm7I64U for ; Sun, 22 Mar 2015 09:34:01 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 1FBA51A8A63 for ; Sun, 22 Mar 2015 09:34:01 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so108210147obd.3 for ; Sun, 22 Mar 2015 09:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BSqdFuuKCfZ1tG31YCyo2TGE2VRS5rNjQPnr1PAEwKc=; b=xMMn+gf3fKn8fAx++zn9Pj99PznpphDKsuev8yoHyGEKkPXIHI5QYxOqc6VCwC44hE 8zOroTH8Ws9VPmnP1a2M0b/eX709ovBfmGKonZd7W9h2wu+8IGqFElRVnpPnk+M6yBe7 ASVYIw5TFMqZ/QFoR8vaAYerD1MmI+sbeA9L105nXnMqPJLO/dsfaiV/ZfhGS7uxsSPc o5YrDU0YpuC+/A9c7I4ysnTM68TTB8uvryGn2mceoiNZ2XdbEXDjomZXMMwA9FMGM6lq 8Z2Aoy2DxCdNo6nPZWkHAYZk92B7JB1aNoewqg7JpKrr/CV31yJqRNuTbfJ+U//Eb4IT FY4w== MIME-Version: 1.0 X-Received: by 10.202.229.141 with SMTP id c135mr68595556oih.44.1427042040570; Sun, 22 Mar 2015 09:34:00 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Sun, 22 Mar 2015 09:34:00 -0700 (PDT) Date: Sun, 22 Mar 2015 09:34:00 -0700 Message-ID: From: Martin Thomson To: "tools-discuss@ietf.org Discussion" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Tools-discuss] Missing 's' on week-view X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 16:34:02 -0000 https://datatracker.ietf.org/meeting/92/week-view.html Includes an inline dump of the sessions. The links in here are all http://, which causes the agenda to fail to render on some browsers. From nobody Sun Mar 22 10:32:20 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F3B1A01D5 for ; Sun, 22 Mar 2015 10:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxwUuOSfxlGr for ; Sun, 22 Mar 2015 10:32:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 21C7E1A0006 for ; Sun, 22 Mar 2015 10:32:17 -0700 (PDT) Received: from [2001:67c:370:176:a0d3:88dc:b030:a71a] (port=62116 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YZjjT-0002LW-VT; Sun, 22 Mar 2015 10:32:16 -0700 Message-ID: <550EFC95.9070502@levkowetz.com> Date: Sun, 22 Mar 2015 18:32:05 +0100 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Thomson , "tools-discuss@ietf.org Discussion" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kTGMJMBop7stLLuIdu9T0tPAsfcPSGdtd" X-SA-Exim-Connect-IP: 2001:67c:370:176:a0d3:88dc:b030:a71a X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, tools-discuss@ietf.org, martin.thomson@gmail.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: Subject: Re: [Tools-discuss] Missing 's' on week-view X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 17:32:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kTGMJMBop7stLLuIdu9T0tPAsfcPSGdtd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Martin, On 2015-03-22 17:34, Martin Thomson wrote: > https://datatracker.ietf.org/meeting/92/week-view.html >=20 > Includes an inline dump of the sessions. The links in here are all > http://, which causes the agenda to fail to render on some browsers. Right. Fixed. Thanks for the alert! Henrik --kTGMJMBop7stLLuIdu9T0tPAsfcPSGdtd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJVDvyfAAoJEE6bV0uPuxcavgwP/0P5gT6BDnk7ZcabQHACmGgD 6FMbolppLOTEBfmJk5zdF/JtvSS/CUIBNt+LavQFUtnMbFCS9yM6WlHmjlJius1P 5E36AQsCyftfzoJiWuyK+Rw63BgbtROBg5zXvNk9JiMrJHuS7bnEs4rrkBNq8MKX 8H3yFeX1gAyYOQL56zmlT/tWNXVOnLTmARpRHM2r9kjoiG5BUBMTAhEV94X3bSH7 EWqFX85xnNLbKqHE2bSmu2ov2aIAxiAcMuFP62xl//z1Z+P6VshwZzPGhduK4Xl5 pI6VsHhEa//C+8keM94jp1WA1CdsTLuiqJ80Et0HtU/lC8p9umaPODMz8g+BtTdO aAjbRhbik+w2tEFL/hI6DnydXyTdaG81m0AM+1XrgcpzsR6ozLb2L+16YNGeQpbP a/ZXaAupnp7W8EafAx/vZqWjGhxl5EgPOoYQCvohC3rh3V62JctYApYI8/lRtCZK fJHlQzYvYmzAw/LZZDuZlQ02U5YdqroLcuVZ4fvDiOq6OZCmf+l/KnzukneH4bgh SDX4vuF7huRCO38P1zHFhv8AkkS6CBPqD0VMwca5Wr2iQwKeICW/pO/AXDuFzMEB kOEQH1tsxdvcRxrvsYXF3oLpKLkAOonfrCI0duJVhx7KdqGcfOPZo4iqNrePWMj0 sKOWuT7Ug9I8YjyBIBNl =5R4i -----END PGP SIGNATURE----- --kTGMJMBop7stLLuIdu9T0tPAsfcPSGdtd--