From nobody Mon Jun 1 12:51:54 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CD31B30C6 for ; Mon, 1 Jun 2015 12:51:53 -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 aIhgSf0BQfKc for ; Mon, 1 Jun 2015 12:51:52 -0700 (PDT) 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 069D01B2F63 for ; Mon, 1 Jun 2015 12:51:52 -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 t51JppQd046991 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 1 Jun 2015 14:51:51 -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: <556CB7D2.2090607@nostrum.com> Date: Mon, 01 Jun 2015 14:51:46 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rfc-design@rfc-editor.org, IETF Tools Development Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TOOLS-DEVELOPMENT] Update to the PublicationFormatter SoW X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 19:51:53 -0000 This version updates some links, and removes a list of preparation actions, pointing to draft-hoffman-rfcv3-preptool instead. http://www.nostrum.com/~rjsparks/PublicationFormatter-05.docx http://www.nostrum.com/~rjsparks/PublicationFormatter-05.pdf RjS From nobody Tue Jun 2 14:39:48 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66AE1A92EA for ; Tue, 2 Jun 2015 14:39:46 -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 4ty2cSD6DeNW for ; Tue, 2 Jun 2015 14:39:45 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1021A0013 for ; Tue, 2 Jun 2015 14:39:45 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id DEF609A4014 for ; Tue, 2 Jun 2015 17:39:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id KspfjHfdR3PD for ; Tue, 2 Jun 2015 17:38:14 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 29B809A4029 for ; Tue, 2 Jun 2015 17:39:14 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 2 Jun 2015 17:39:03 -0400 Message-Id: <0AE66200-0B10-4D54-8B54-F15911505FF4@vigilsec.com> To: IETF Tools Development Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [TOOLS-DEVELOPMENT] Tools Call Agenda for 9 June 2015 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:39:46 -0000 Tools Call Agenda -- 9 June 2015 at 13:00 Eastern 1. Datatracker Projects - Expected Datatracker Releases -- Robert and Henrik -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan - Submission tool automatically generates text from XML -- Robert - Liaison Tool improvements -- Robert - Performance improvements -- Henrik - Review Tracking -- Robert - iCal for face-to-face and virtual interim meetings -- Robert - Automation for WG iCal creation and deletion -- Robert - Making email sending table driven -- Henrik and Robert - Upload PPT or PDF or both for meeting materials -- Robert 2. Community & Other Projects - Present a directory view of active, archived, and unknown I-Ds -- Robert - Improve infrastructure for finding and fetching artifacts -- Robert - IETF Website Makeover -- Joe and Greg 3. RFC Services Projects - xml2rfc bug fixes -- Alice and Henrik - RFC Editor Website Makeover -- Alice and Heather - RFC Format-related SOWs -- Robert - RSE's Design Teams -- Heather 4. Transition of Mission Critical Tools - Moving issue trackers and wikis for IETF WGs on ietf.org 5. Server Infrastructure - iCal servers -- AMS -- How can we support calendars for "all interim meetings"? -- How can we support calendars for "interim meetings in an area"? - IMAP access to the email archives -- Robert - VM Architecture for Servers -- Robert 6. IDIQ Contractors - RFP for more IDIQ contractors -- Ray 7. Parking Lot - Mentor Support Tool -- AMS - RFC Editor automatic stats and reporting RFP -- Heather - Author information for very old I-Ds in the datatracker -- Robert - Replace I-Ds in proceedings with links to archive copy? - Can the test process for the NomCom Tool be more comprehensive? 8. AOB From nobody Wed Jun 3 12:12:15 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4BB1B29C8 for ; Wed, 3 Jun 2015 12:12:12 -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 XqsHQBShh-4K for ; Wed, 3 Jun 2015 12:12:09 -0700 (PDT) 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 C79CE1AD0C4 for ; Wed, 3 Jun 2015 12:12:09 -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 t53JC8Yc091382 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 3 Jun 2015 14:12:09 -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: <556F5183.2030602@nostrum.com> Date: Wed, 03 Jun 2015 14:12:03 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tools-development@ietf.org References: <0AE66200-0B10-4D54-8B54-F15911505FF4@vigilsec.com> In-Reply-To: <0AE66200-0B10-4D54-8B54-F15911505FF4@vigilsec.com> Content-Type: multipart/alternative; boundary="------------000000000607010704040908" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda for 9 June 2015 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 19:12:12 -0000 This is a multi-part message in MIME format. --------------000000000607010704040908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Some initial notes to help keep the call within time. On 6/2/15 4:39 PM, Russ Housley wrote: > Tools Call Agenda -- 9 June 2015 at 13:00 Eastern > > 1. Datatracker Projects > - Expected Datatracker Releases -- Robert and Henrik > -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan That link currently says: Jun Support for xml-only draft submission Jun ScheduledSession, meeting cutoffs, floorplan, and possibly document tags schema change Jun Leveraging CDN for serving external static libs Jul Liaison tool improvements Jul Improvements to when and where the tracker sends email There is also a moderate-sized maintenance release coming up that includes addressing facelift issues, improving capturing IANA comments, handling some ART issues, and adding more meeting support for the secretariat. > - Submission tool automatically generates text from XML -- Robert Henrik is working on this one - it will be the first of the releases above. > - Liaison Tool improvements -- Robert On track. Ryan is finishing the new forms and workflow functionality the project required. I'll be vetting the "default initial contacts" for each external group through the liaison oversight program soon. > - Performance improvements -- Henrik > - Review Tracking -- Robert The document is in Jari's hands (AD Evaluation). Pete Resnick has agreed to shepherd and will provide a shepherd writeup next week. I have minor comments from Jari and from Brian Carpenter to incorporate. > - iCal for face-to-face and virtual interim meetings -- Robert I am still thinking through building and serving these calendars directly from the tracker. So far, it looks like it will be fairly straightforward. > - Automation for WG iCal creation and deletion -- Robert Waiting to do this until we have more experience from the groups that are trying to use these calendars. > - Making email sending table driven -- Henrik and Robert Nothing new to report - this is in the queue as shown at the top of this message. > - Upload PPT or PDF or both for meeting materials -- Robert I'll follow up on this separately. > > 2. Community & Other Projects > - Present a directory view of active, archived, and unknown I-Ds -- Robert > - Improve infrastructure for finding and fetching artifacts -- Robert Nothing new to report on those two items. > - IETF Website Makeover -- Joe and Greg > > 3. RFC Services Projects > - xml2rfc bug fixes -- Alice and Henrik > - RFC Editor Website Makeover -- Alice and Heather > - RFC Format-related SOWs -- Robert There is a revision of the PublicationFormatter that takes the design-team's work on draft-hoffman-rfcv3-preptool into account. Both of those need review please. > - RSE's Design Teams -- Heather > > 4. Transition of Mission Critical Tools > - Moving issue trackers and wikis for IETF WGs on ietf.org > > 5. Server Infrastructure > - iCal servers -- AMS > -- How can we support calendars for "all interim meetings"? > -- How can we support calendars for "interim meetings in an area"? > - IMAP access to the email archives -- Robert This got a lot of time this cycle: * We spent some time working out why the authorization system would frequently stop working. It turned out to be a consequence of not having many users - connections to MySQL were timing out. * We spent a lot of time repairing bad dates in the messages in several lists, and cleaning up some critical messages that were parsed out of the mbox files incorrectly. We've identified a couple of classes of other messages that need repair (affecting a significant part of the archive), but this is not blocking. * I am recruiting the next round of testers and getting them started on testing. So far we've gotten positive feedback from Cyrus. > - VM Architecture for Servers -- Robert Nothing new to report. > > 6. IDIQ Contractors > - RFP for more IDIQ contractors -- Ray > > 7. Parking Lot > - Mentor Support Tool -- AMS > - RFC Editor automatic stats and reporting RFP -- Heather > - Author information for very old I-Ds in the datatracker -- Robert > - Replace I-Ds in proceedings with links to archive copy? > - Can the test process for the NomCom Tool be more comprehensive? > > 8. AOB > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --------------000000000607010704040908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Some initial notes to help keep the call within time.


On 6/2/15 4:39 PM, Russ Housley wrote:
Tools Call Agenda -- 9 June 2015 at 13:00 Eastern

1. Datatracker Projects
  - Expected Datatracker Releases -- Robert and Henrik
    -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan
That link currently says:

Jun Support for xml-only draft submission
Jun ScheduledSession, meeting cutoffs, floorplan, and possibly document tags schema change
Jun Leveraging CDN for serving external static libs
Jul Liaison tool improvements
Jul Improvements to when and where the tracker sends email

There is also a moderate-sized maintenance release coming up that includes addressing
facelift issues, improving capturing IANA comments, handling some ART issues,  and adding
more meeting support for the secretariat. 
  - Submission tool automatically generates text from XML -- Robert
Henrik is working on this one - it will be the first of the releases above.
  - Liaison Tool improvements -- Robert
On track. Ryan is finishing the new forms and workflow functionality the project required.
I'll be vetting the "default initial contacts" for each external group through the liaison oversight program soon.

  - Performance improvements -- Henrik
  - Review Tracking -- Robert
The document is in Jari's hands (AD Evaluation). Pete Resnick has agreed to shepherd and will
provide a shepherd writeup next week. I have minor comments from Jari and from Brian Carpenter
to incorporate.
  - iCal for face-to-face and virtual interim meetings -- Robert
I am still thinking through building and serving these calendars directly from the tracker.
So far, it looks like it will be fairly straightforward.
  - Automation for WG iCal creation and deletion -- Robert
Waiting to do this until we have more experience from the groups that are trying to use these calendars.
  - Making email sending table driven -- Henrik and Robert
Nothing new to report - this is in the queue as shown at the top of this message.
  - Upload PPT or PDF or both for meeting materials -- Robert
I'll follow up on this separately.

2. Community & Other Projects
  - Present a directory view of active, archived, and unknown I-Ds	-- Robert
  - Improve infrastructure for finding and fetching artifacts -- Robert
Nothing new to report on those two items.
  - IETF Website Makeover -- Joe and Greg

3. RFC Services Projects
  - xml2rfc bug fixes -- Alice and Henrik
  - RFC Editor Website Makeover -- Alice and Heather
  - RFC Format-related SOWs -- Robert
There is a revision of the PublicationFormatter that takes the design-team's work on
draft-hoffman-rfcv3-preptool into account. Both of those need review please.
  - RSE's Design Teams -- Heather

4. Transition of Mission Critical Tools
  - Moving issue trackers and wikis for IETF WGs on ietf.org

5. Server Infrastructure
  - iCal servers -- AMS
    -- How can we support calendars for "all interim meetings"?
    -- How can we support calendars for "interim meetings in an area"?
  - IMAP access to the email archives -- Robert
This got a lot of time this cycle:
* We spent some time working out why the authorization system would frequently stop working.
It turned out to be a consequence of not having many users - connections to MySQL were timing out.

* We spent a lot of time repairing bad dates in the messages in several lists, and cleaning up some
critical messages that were parsed out of the mbox files incorrectly. We've identified a couple of classes
of other messages that need repair (affecting a significant part of the archive), but this is not blocking.

* I am recruiting the next round of testers and getting them started on testing. So far we've gotten
positive feedback from Cyrus.

  - VM Architecture for Servers -- Robert
Nothing new to report.

6. IDIQ Contractors
  - RFP for more IDIQ contractors -- Ray

7. Parking Lot
  - Mentor Support Tool -- AMS
  - RFC Editor automatic stats and reporting RFP -- Heather
  - Author information for very old I-Ds in the datatracker -- Robert
  - Replace I-Ds in proceedings with links to archive copy?
  - Can the test process for the NomCom Tool be more comprehensive?

8. AOB

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

--------------000000000607010704040908-- From nobody Wed Jun 3 16:44:07 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAB01A038E for ; Wed, 3 Jun 2015 16:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 OYnZy8YziNwE for ; Wed, 3 Jun 2015 16:44:03 -0700 (PDT) Received: from sjmda13.webex.com (sjmda13.webex.com [64.68.124.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05021A0387 for ; Wed, 3 Jun 2015 16:44:03 -0700 (PDT) Received: from gjtx3tc102.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-2.webex.com [64.68.121.246]) by sjmda13.webex.com (Postfix) with ESMTP id 76849C2498 for ; Wed, 3 Jun 2015 23:44:03 +0000 (GMT) Received: from gjtx3tc102.webex.com (localhost [127.0.0.1]) by gjtx3tc102.webex.com (Postfix) with ESMTP id 4ED0377 for ; Wed, 3 Jun 2015 23:44:03 +0000 (GMT) Date: Wed, 3 Jun 2015 23:44:03 +0000 (GMT) From: Ray Pelletier To: tools-development@ietf.org Message-ID: <1760600135.3070.1433375043321.JavaMail.nobody@gjtx3tc102.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_3068_1356844146.1433375043320" X-Priority: 3 Importance: normal Archived-At: Subject: [TOOLS-DEVELOPMENT] WebEx meeting invitation: Tools Cmte X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rpelletier@isoc.org List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 23:44:06 -0000 ------=_Part_3068_1356844146.1433375043320 Content-Type: multipart/Alternative; boundary="----=_Part_3069_350714329.1433375043321" ------=_Part_3069_350714329.1433375043321 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKUmF5IFBlbGxldGllciBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVl dGluZy4KCgpUb29scyBDbXRlClR1ZXNkYXksIEp1bmUgOSwgMjAxNQoxOjAwIHBtICB8ICBFYXN0 ZXJuIERheWxpZ2h0IFRpbWUgKE5ldyBZb3JrLCBHTVQtMDQ6MDApICB8ICAxIGhyCgoKSk9JTiBX RUJFWCBNRUVUSU5HCmh0dHBzOi8vd29ya2dyZWVuLndlYmV4LmNvbS93b3JrZ3JlZW4vai5waHA/ TVRJRD1tMDBmMDliYjgxOTVjYmEyY2Y1N2JjNWY1NmUzZDA5NjAKTWVldGluZyBudW1iZXI6IDY3 MiAzMTUgNDA2CgoNCkpPSU4gQlkgUEhPTkUNCjEtODc3LTY2OC00NDkwIENhbGwtaW4gdG9sbC1m cmVlIG51bWJlciAoVVMvQ2FuYWRhKSAKMS00MDgtNzkyLTYzMDAgQ2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKQpBY2Nlc3MgY29kZTogNjcyIDMxNSA0MDYKCkdsb2JhbCBjYWxsLWluIG51 bWJlcnM6Cmh0dHBzOi8vd29ya2dyZWVuLndlYmV4LmNvbS93b3JrZ3JlZW4vZ2xvYmFsY2FsbGlu LnBocD9zZXJ2aWNlVHlwZT1NQyZFRD0yODQ3MTA3NzMmdG9sbEZyZWU9MQoKVG9sbC1mcmVlIGRp YWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jl c3RyaWN0aW9ucy5wZGYNCg0KCkFkZCB0aGlzIG1lZXRpbmcgdG8geW91ciBjYWxlbmRhcjoKaHR0 cHM6Ly93b3JrZ3JlZW4ud2ViZXguY29tL3dvcmtncmVlbi9qLnBocD9NVElEPW00YTFlMGM5YThj YmFhZDhmNGNkMDY1YzgwMDY0ODhkYg0KDQoKQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFj dCBzdXBwb3J0IGhlcmU6Cmh0dHBzOi8vd29ya2dyZWVuLndlYmV4LmNvbS93b3JrZ3JlZW4vbWMK CgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBh bGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9u IHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0 dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0 byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRl ZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhl IHNlc3Npb24uCg== ------=_Part_3069_350714329.1433375043321 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBSYXkg UGVsbGV0aWVyIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJFeCBtZWV0aW5nLgogICAgICAg ICAgICAgICAgCSAgICAgICAgICAgPC90ZD4KICAgICAgPC90cj4KPC90YWJsZT4KCgoKCjx0YWJs ZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+ Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSAgd2lkdGg9IjEwMCUiPgoJCQkJ CQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHg7IGNvbG9yOiM0RDRENEQi PgoJCQkJCQkJCQk8Yj5Ub29scyBDbXRlPC9iPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJ CQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+VHVlc2RheSwgSnVuZSA5 LCAyMDE1CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdp bjowcHgiPgoJCQkJCQkJCTx0ZD4xOjAwIHBtJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwO0Vhc3Rl cm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkmbmJzcDsmbmJzcDt8Jm5ic3A7 Jm5ic3A7MSBocgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKPHRh YmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4 Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRv OyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJj b2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJCQkJCQkJPGEgaHJlZj0iaHR0cHM6Ly93 b3JrZ3JlZW4ud2ViZXguY29tL3dvcmtncmVlbi9qLnBocD9NVElEPW0wMGYwOWJiODE5NWNiYTJj ZjU3YmM1ZjU2ZTNkMDk2MCIKCQkJCQkJCQkJCXN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtm b250LXNpemU6MTZweDtjb2xvcjojMDBBRkY5Ij4KCQkJCQkJCQkJCTxiPkpvaW4gV2ViRXggbWVl dGluZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8 L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0 YW50Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkIHN0eWxlPSJw YWRkaW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJCQkJTWVldGluZyBudW1iZXI6CgkJCQkJCQkJPC90 ZD4KCQkJCQkJCQk8dGQ+NjcyIDMxNSA0MDYKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJ CQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPjwvdGQ+CgkJ CQkJCQkJPHRkPjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxl Pjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5i c3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4 Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0 ZD48Yj4xLTg3Ny02NjgtNDQ5MDwvYj4mbmJzcDtDYWxsLWluIHRvbGwtZnJlZSBudW1iZXIgKFVT L0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS00MDgtNzky LTYzMDA8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48 dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD5BY2Nlc3MgY29kZTombmJzcDs2NzIgMzE1IDQwNjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48YSBocmVmPSJodHRwczovL3dvcmtn cmVlbi53ZWJleC5jb20vd29ya2dyZWVuL2dsb2JhbGNhbGxpbi5waHA/c2VydmljZVR5cGU9TUMm RUQ9Mjg0NzEwNzczJnRvbGxGcmVlPTEiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250 LXNpemU6MTNweDtjb2xvcjojMDBBRkY5Ij5HbG9iYWwgY2FsbC1pbiBudW1iZXJzPC9hPiZuYnNw OyZuYnNwO3wmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9s bGZyZWVfcmVzdHJpY3Rpb25zLnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQt c2l6ZToxM3B4O2NvbG9yOiMwMEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8 L2E+PC90ZD48L3RyPjwvdGFibGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0 YWJsZT48dHI+PHRkIHN0eWxlPSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly93b3Jr Z3JlZW4ud2ViZXguY29tL3dvcmtncmVlbi9qLnBocD9NVElEPW00YTFlMGM5YThjYmFhZDhmNGNk MDY1YzgwMDY0ODhkYiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjk7 IGZvbnQtc2l6ZToxM3B4Ij5BZGQgdGhpcyBtZWV0aW5nPC9hPiB0byB5b3VyIGNhbGVuZGFyLjwv dGQ+PC90cj48L3RhYmxlPgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0 ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+CiAg ICA8dHI+CiAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6ICM2NjY2NjY7Ij4KICAgICAgICBDYW4ndCBqb2luIHRoZSBtZWV0aW5nPwogICAg IAk8YSBocmVmPSJodHRwczovL3dvcmtncmVlbi53ZWJleC5jb20vd29ya2dyZWVuL21jIiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6IzAwQUZGOTtmb250LWNvbG9yOiMwMEFGRjk7Ij4KICAgICAgICAJQ29udGFjdCBzdXBw b3J0LjwvYT4KCQk8L3RkPgogICAgPC90cj4KPC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGlu ZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoxMHB4Ij4mbmJzcDs8L3RkPjwvdHI+ PC90YWJsZT4KCQkJCQkJPHRhYmxlPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9u dC1zaXplOjEycHg7Y29sb3I6ICNBMEEwQTA7Ij4KCQkJCQkJCQkJSU1QT1JUQU5UIE5PVElDRTog UGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhl ciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hp Y2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlz IHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJ ZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25j ZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjwvdGQ+CgkJCQkJ CQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJPC90ZD4KCQkJPC90cj4KCQk8L3RhYmxlPgoJPC90 ZD4KICAgPC90cj4KPC90YWJsZT4KCjwvYm9keT4= ------=_Part_3069_350714329.1433375043321-- ------=_Part_3068_1356844146.1433375043320 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86dG9vbHMtZGV2ZWxvcG1lbnRAaWV0Zi5vcmcKT1JH QU5JWkVSO0NOPSJSYXkgUGVsbGV0aWVyIjpNQUlMVE86cnBlbGxldGllckBpc29jLm9yZwpEVFNU QVJUO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNTA2MDlUMTMwMDAwCkRURU5EO1RaSUQ9IkVhc3Rl cm4gVGltZSI6MjAxNTA2MDlUMTQwMDAwCkxPQ0FUSU9OOmh0dHBzOi8vd29ya2dyZWVuLndlYmV4 LmNvbS93b3JrZ3JlZW4KVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDMzMzc1MDQzClVJRDo0MmQw MWY0Yi1mOWU1LTQ5ZmEtYmZjMi02YzJjNzQ3ZmI3MGQKRFRTVEFNUDoyMDE1MDYwOVQxNzAwMDBa CkRFU0NSSVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly93b3JrZ3JlZW4u d2ViZXguY29tL3dvcmtncmVlbi9qLnBocD9NVElEPW1mYjdlMzUzMmFjYTg5M2U5MjcyNjc0YjIz MmE0MjFjZFxuTWVldGluZyBudW1iZXI6IDY3MiAzMTUgNDA2XG5cblxuSk9JTiBCWSBQSE9ORVxu MS04NzctNjY4LTQ0OTAgQ2FsbC1pbiB0b2xsLWZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIFxuMS00 MDgtNzkyLTYzMDAgQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuQWNjZXNzIGNvZGU6 IDY3MiAzMTUgNDA2XG5cbkdsb2JhbCBjYWxsLWluIG51bWJlcnM6XG5odHRwczovL3dvcmtncmVl bi53ZWJleC5jb20vd29ya2dyZWVuL2dsb2JhbGNhbGxpbi5waHA/c2VydmljZVR5cGU9TUMmRUQ9 Mjg0NzEwNzczJnRvbGxGcmVlPTFcblxuVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiBc bmh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmXG5cblxu XG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZTpcbmh0dHBzOi8v d29ya2dyZWVuLndlYmV4LmNvbS93b3JrZ3JlZW4vbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQ bGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVy IGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGlj aCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMg c2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElm IHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNl cm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVT QztGTVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxC Uj4gPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vd29y a2dyZWVuLndlYmV4LmNvbS93b3JrZ3JlZW4vai5waHA/TVRJRD1tZmI3ZTM1MzJhY2E4OTNlOTI3 MjY3NGIyMzJhNDIxY2QiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlh bCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9GT05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0 ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRp bmcgbnVtYmVyOjwvRk9OVD4JCQkJCTwvdGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj42NzIgMzE1IDQwNjwvRk9OVD4JCQkJCTwvdGQ+ CQkJCTwvdHI+CQkJPC90YWJsZT4JCQkJCTwvRk9OVD48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklB TCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwi PjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9u ZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJh cmlhbCI+PHN0cm9uZz4xLTg3Ny02NjgtNDQ5MDwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbC1m cmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTQwOC03OTItNjMwMDwvc3Ryb25n PiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkFjY2VzcyBjb2RlOiA2 NzIgMzE1IDQwNjwvRk9OVD4mbmJzcDsgPEJSPjxhIGhyZWY9Imh0dHBzOi8vd29ya2dyZWVuLndl YmV4LmNvbS93b3JrZ3JlZW4vZ2xvYmFsY2FsbGluLnBocD9zZXJ2aWNlVHlwZT1NQyZFRD0yODQ3 MTA3NzMmdG9sbEZyZWU9MSI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFy aWFsIj5HbG9iYWwgY2FsbC1pbiBudW1iZXJzPC9GT05UPjwvYT48Rk9OVCBTSVpFPSIxIiBGQUNF PSJBUklBTCI+Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzwvRk9OVD48YSBocmVmPSJodHRwOi8v d3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0i MSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFsIj5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmlj dGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwvRk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxG T05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4g dGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJodHRwczovL3dvcmtncmVlbi53ZWJleC5jb20v d29ya2dyZWVuL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFs Ij5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBD T0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L0ZPTlQ+PC9GT05U PgpTVU1NQVJZOlRvb2xzIENtdGUKUFJJT1JJVFk6NQpDTEFTUzpQVUJMSUMKQkVHSU46VkFMQVJN ClRSSUdHRVI6LVBUNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJT046UmVtaW5kZXIKRU5EOlZB TEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK ------=_Part_3068_1356844146.1433375043320-- From nobody Tue Jun 9 11:02:25 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23491B2DF1 for ; Tue, 9 Jun 2015 11:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 a6pp8PC35BIa for ; Tue, 9 Jun 2015 11:02:22 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0056.outbound.protection.outlook.com [207.46.100.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2C91B2DAE for ; Tue, 9 Jun 2015 11:02:22 -0700 (PDT) Received: from BLUPR0601MB1553.namprd06.prod.outlook.com (25.163.211.143) by BLUPR0601MB1475.namprd06.prod.outlook.com (25.163.86.13) with Microsoft SMTP Server (TLS) id 15.1.184.17; Tue, 9 Jun 2015 18:02:19 +0000 Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [192.168.0.22] (72.237.59.193) by BLUPR0601MB1553.namprd06.prod.outlook.com (25.163.211.143) with Microsoft SMTP Server (TLS) id 15.1.184.17; Tue, 9 Jun 2015 18:02:17 +0000 From: Ray Pelletier Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <9ECA77DF-C467-4D1B-ABDC-7B05DBACAF63@isoc.org> Date: Tue, 9 Jun 2015 14:02:27 -0400 To: IETF Tools Development MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Originating-IP: [72.237.59.193] X-ClientProxiedBy: BLUPR11CA0078.namprd11.prod.outlook.com (10.141.30.46) To BLUPR0601MB1553.namprd06.prod.outlook.com (25.163.211.143) X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0601MB1553; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0601MB1475; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BLUPR0601MB1553; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0601MB1553; X-Forefront-PRVS: 06022AA85F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6049001)(5423002)(92566002)(77096005)(19580395003)(50466002)(86362001)(50226001)(46102003)(229853001)(82746002)(77156002)(62966003)(23676002)(450100001)(33656002)(5001960100002)(42186005)(47776003)(1720100001)(50986999)(36756003)(5001920100001)(117156001)(66066001)(15975445007)(107886002)(40100003)(83716003)(122386002)(230783001)(189998001)(57306001)(110136002)(48284002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0601MB1553; H:[192.168.0.22]; FPR:; SPF:None; MLV:sfv; LANG:en; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2015 18:02:17.0800 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0601MB1553 X-OriginatorOrg: isoc.org Archived-At: Subject: [TOOLS-DEVELOPMENT] Rough Notes Tools Call 2015-06-09 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 18:02:24 -0000 Tools Call 9 Jun 15 Attendees Robert Ray Alexa Greg Heather Karen Lou Russ Ryan Matt Glen Tony Henrik Kathleen 1. Datatracker Projects - Expected Datatracker Releases -- Robert and Henrik -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan Robert - That link currently says: Jun Support for xml-only draft submission Jun ScheduledSession, meeting cutoffs, floorplan, and possibly document tags schema change Jun Leveraging CDN for serving external static libs Jul Liaison tool improvements Jul Improvements to when and where the tracker sends email There is also a moderate-sized maintenance release coming up that includes addressing facelift issues, improving capturing IANA comments, handling some ART issues, and adding more meeting support for the secretariat. - Submission tool automatically generates text from XML -- Robert Henrik is working on this one - it will be the first of the releases above. - Liaison Tool improvements -- Robert On track. Ryan is finishing the new forms and workflow functionality the project required. I'll be vetting the "default initial contacts" for each external group through the liaison oversight program soon. A fair amount of work to do. Getting most of Ryan=E2=80=99s time. End = of July timeline to getting it done. - Performance improvements -- Henrik Moving static pages so CDN could help us on reduced latency; an upcoming release - Review Tracking -- Robert The document is in Jari's hands (AD Evaluation). Pete Resnick has agreed to shepherd and will provide a shepherd writeup next week. I have minor comments from Jari and from Brian Carpenter to incorporate. Right at Last Call now - iCal for face-to-face and virtual interim meetings -- Robert I am still thinking through building and serving these calendars directly from the tracker. So far, it looks like it will be fairly straightforward. Need some cycles to finish. Expect to send a readout on this end of next week, hopefully done and part of a maintenance release update; but there may still be surprises. - Automation for WG iCal creation and deletion -- Robert Waiting to do this until we have more experience from the groups that are trying to use these calendars. - Making email sending table driven -- Henrik and Robert Nothing new to report - this is in the queue as shown at the top of this message. - Upload PPT or PDF or both for meeting materials -- Robert Henrik has provided info on these tools and Ryan is reviewing to see if AMS can use. Alexa - we will have in place. 2. Community & Other Projects - Present a directory view of active, archived, and unknown I-Ds -- Robert - Improve infrastructure for finding and fetching artifacts -- Robert Nothing new to report on those two items These two projects - what needs to be done with 1st one - something that works cleanly with RFCdiff and archive, and which things work with subpoenas and don=E2=80=99t. Robert - I think we have that. 2nd - want to move some of these directories around to make Apache and rsync work better. Won=E2=80=99t change anything people see; documentation is being updated if things move - IETF Website Makeover -- Joe and Greg Greg - Joe has convened the Community Review Committee and will begin work this week; on track. Hope to have something for the community by Prague. 3. RFC Services Projects - xml2rfc bug fixes -- Alice and Henrik Alice - one more bug with new DOI. Not keeping us from doing job. Henrik - still a number of bugs, none critical. Lower in the queue. Not needed to be tracked. Don=E2=80=99t track other system bugs. - RFC Editor Website Makeover -- Alice and Heather On track and now working on dynamic data; may have an update for stream manager lunch. - RFC Format-related SOWs -- Robert There is a revision of the PublicationFormatter that takes the design-team's work on draft-hoffman-rfcv3-preptool into account. Both of those need review please. An important chunk of processing; places where decisions made to pull into all external content for draft submission tool; some sections pretty straight forward; includes policy that folks should think about. Ee want to keep the artifact around in a draft repository, this is new. When might the SOWs be put out to bid? Robert - July - August. Heather - concur. Still some major chasms to close. - RSE's Design Teams -- Heather Call this afternoon. 4. Transition of Mission Critical Tools - Moving issue trackers and wikis for IETF WGs on ietf.org Last time - Henrik and Glen to meet in Prague. 5. Server Infrastructure - IMAP access to the email archives -- Robert This got a lot of time this cycle: * We spent some time working out why the authorization system would frequently stop working. It turned out to be a consequence of not having many users - connections to MySQL were timing out. * We spent a lot of time repairing bad dates in the messages in several lists, and cleaning up some critical messages that were parsed out of the mbox files incorrectly. We've identified a couple of classes of other messages that need repair (affecting a significant part of the archive), but this is not blocking. Being fixed by scripts, not by hand. * I am recruiting the next round of testers and getting them started on testing. So far we've gotten positive feedback from Cyrus. Production - by Prague. - VM Architecture for Servers -- Robert Nothing new to report. FTP servers 6. IDIQ Contractors - RFP for more IDIQ contractors -- Ray No expressions of interest as yet, but there are some folks who are interested. So, there might be 3 coming in soon. 7. Parking Lot - Mentor Support Tool -- AMS - RFC Editor automatic stats and reporting RFP -- Heather - Author information for very old I-Ds in the datatracker -- Robert - Replace I-Ds in proceedings with links to archive copy? - Can the test process for the NomCom Tool be more comprehensive? 8. AOB Robert - some small SOWs for handling interim meetings management and manual submission of IDs requests. On the cusp of being bid out. Kathleen - curious as to state of requests from IESG Robert - =E2=80=9Cdiscuss box=E2=80=9D all fixed, in an upcoming bug fix = next week. From nobody Tue Jun 9 11:18:03 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DC01B2E2C for ; Tue, 9 Jun 2015 11:18: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 H15ULHXBTiNQ for ; Tue, 9 Jun 2015 11:17:59 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 85E1B1B2E2B for ; Tue, 9 Jun 2015 11:17:59 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so16975337igb.0 for ; Tue, 09 Jun 2015 11:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=/Zg+q6ZEH90O5yL54enAU60xRsXJzGUzaVuzehoiwJA=; b=Kq/EAaikUJOeAY6ooLyT197P97bHUmIepAN9y9fx//d11/sh0LEbEOxnyA9IHIBshj ak1opRGym7FkU4xv/bDrFiG74TyoAmIL+PgNO1aNIF7Y5hu7E7FdtVkQsWsuij83rHpU OU3iZFBDbdBvhQKtnd4b92tleaCp9RE68CzbW/9TzHkB0Hg9SZWvnBnVZSpLWh0KSlJk QGN7PX0CkoPnWMoW+5lMrW62d1RGMjMaJ9vFcSXnm/3MSUIzZc7qluy1mExzTWkC5mfw HzqC1M4FqSA6LUtBiJkWOJI5qww07xRqpfLW//IRxMcWnyPOdPn7mxtusC8MCjDu3fCq aIMg== X-Received: by 10.43.163.129 with SMTP id mo1mr42989icc.61.1433873425439; Tue, 09 Jun 2015 11:10:25 -0700 (PDT) Received: from ?IPv6:2601:9:400:ac2:eded:a966:d8e9:69cf? ([2601:9:400:ac2:eded:a966:d8e9:69cf]) by mx.google.com with ESMTPSA id z6sm1609715ign.13.2015.06.09.11.10.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jun 2015 11:10:24 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_92BA1D32-5DF6-413E-9AA8-886B7BDEC56C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Bob Hinden In-Reply-To: <9ECA77DF-C467-4D1B-ABDC-7B05DBACAF63@isoc.org> Date: Tue, 9 Jun 2015 11:10:23 -0700 Message-Id: References: <9ECA77DF-C467-4D1B-ABDC-7B05DBACAF63@isoc.org> To: Ray Pelletier X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] Rough Notes Tools Call 2015-06-09 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 18:18:02 -0000 --Apple-Mail=_92BA1D32-5DF6-413E-9AA8-886B7BDEC56C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry I missed the call, I was getting ready for a trip and wasn=E2=80=99t= watching what time it was (other than when I have to leave for the = airport). Bob > On Jun 9, 2015, at 11:02 AM, Ray Pelletier = wrote: >=20 > Tools Call 9 Jun 15 >=20 > Attendees >=20 > Robert > Ray > Alexa > Greg > Heather > Karen > Lou > Russ > Ryan > Matt > Glen > Tony > Henrik > Kathleen >=20 > 1. Datatracker Projects >=20 > - Expected Datatracker Releases -- Robert and Henrik >=20 > -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan >=20 > Robert - >=20 > That link currently says: >=20 > Jun Support for xml-only draft submission >=20 > Jun ScheduledSession, meeting cutoffs, floorplan, and possibly > document tags schema change >=20 > Jun Leveraging CDN for serving external static libs >=20 > Jul Liaison tool improvements >=20 > Jul Improvements to when and where the tracker sends email >=20 > There is also a moderate-sized maintenance release coming up that > includes addressing facelift issues, improving capturing IANA > comments, handling some ART issues, and adding more meeting support > for the secretariat. >=20 >=20 > - Submission tool automatically generates text from XML -- Robert >=20 >=20 > Henrik is working on this one - it will be the first of the releases > above. >=20 >=20 > - Liaison Tool improvements -- Robert >=20 > On track. Ryan is finishing the new forms and workflow functionality > the project required. I'll be vetting the "default initial contacts" > for each external group through the liaison oversight program soon. >=20 > A fair amount of work to do. Getting most of Ryan=E2=80=99s time. End = of > July timeline to getting it done. >=20 > - Performance improvements -- Henrik >=20 > Moving static pages so CDN could help us on reduced latency; an > upcoming release >=20 > - Review Tracking -- Robert >=20 > The document is in Jari's hands (AD Evaluation). Pete Resnick has > agreed to shepherd and will provide a shepherd writeup next week. I > have minor comments from Jari and from Brian Carpenter to > incorporate. >=20 > Right at Last Call now >=20 > - iCal for face-to-face and virtual interim meetings -- Robert >=20 > I am still thinking through building and serving these calendars > directly from the tracker. So far, it looks like it will be fairly > straightforward. >=20 > Need some cycles to finish. Expect to send a readout on this end of > next week, hopefully done and part of a maintenance release update; > but there may still be surprises. >=20 > - Automation for WG iCal creation and deletion -- Robert >=20 > Waiting to do this until we have more experience from the groups > that are trying to use these calendars. >=20 > - Making email sending table driven -- Henrik and Robert >=20 > Nothing new to report - this is in the queue as shown at the top of > this message. >=20 > - Upload PPT or PDF or both for meeting materials -- Robert >=20 > Henrik has provided info on these tools and Ryan is reviewing to see > if AMS can use. Alexa - we will have in place. >=20 >=20 > 2. Community & Other Projects >=20 > - Present a directory view of active, archived, and unknown > I-Ds -- Robert >=20 > - Improve infrastructure for finding and fetching artifacts -- > Robert >=20 > Nothing new to report on those two items >=20 > These two projects - what needs to be done with 1st one - something > that works cleanly with RFCdiff and archive, and which things work > with subpoenas and don=E2=80=99t. Robert - I think we have that. >=20 > 2nd - want to move some of these directories around to make Apache > and rsync work better. Won=E2=80=99t change anything people see; > documentation is being updated if things move >=20 > - IETF Website Makeover -- Joe and Greg >=20 > Greg - Joe has convened the Community Review Committee and will > begin work this week; on track. Hope to have something for the > community by Prague. >=20 > 3. RFC Services Projects >=20 > - xml2rfc bug fixes -- Alice and Henrik >=20 > Alice - one more bug with new DOI. Not keeping us from doing job. > Henrik - still a number of bugs, none critical. Lower in the queue. > Not needed to be tracked. Don=E2=80=99t track other system bugs. >=20 > - RFC Editor Website Makeover -- Alice and Heather >=20 > On track and now working on dynamic data; may have an update for > stream manager lunch. >=20 > - RFC Format-related SOWs -- Robert >=20 > There is a revision of the PublicationFormatter that takes the > design-team's work on draft-hoffman-rfcv3-preptool into account. > Both of those need review please. >=20 > An important chunk of processing; places where decisions made to > pull into all external content for draft submission tool; some > sections pretty straight forward; includes policy that folks should > think about. Ee want to keep the artifact around in a draft > repository, this is new. >=20 > When might the SOWs be put out to bid? >=20 > Robert - July - August. Heather - concur. Still some major chasms > to close. >=20 > - RSE's Design Teams -- Heather >=20 > Call this afternoon. >=20 > 4. Transition of Mission Critical Tools >=20 > - Moving issue trackers and wikis for IETF WGs on ietf.org >=20 > Last time - Henrik and Glen to meet in Prague. >=20 > 5. Server Infrastructure >=20 > - IMAP access to the email archives -- Robert >=20 > This got a lot of time this cycle: >=20 > * We spent some time working out why the authorization system would > frequently stop working. It turned out to be a consequence of not > having many users - connections to MySQL were timing out. >=20 > * We spent a lot of time repairing bad dates in the messages in > several lists, and cleaning up some critical messages that were > parsed out of the mbox files incorrectly. We've identified a couple > of classes of other messages that need repair (affecting a > significant part of the archive), but this is not blocking. >=20 > Being fixed by scripts, not by hand. >=20 > * I am recruiting the next round of testers and getting them started > on testing. So far we've gotten positive feedback from Cyrus. >=20 > Production - by Prague. >=20 > - VM Architecture for Servers -- Robert >=20 > Nothing new to report. >=20 > FTP servers >=20 > 6. IDIQ Contractors >=20 > - RFP for more IDIQ contractors -- Ray >=20 > No expressions of interest as yet, but there are some folks who are > interested. So, there might be 3 coming in soon. >=20 > 7. Parking Lot >=20 > - Mentor Support Tool -- AMS >=20 > - RFC Editor automatic stats and reporting RFP -- Heather >=20 > - Author information for very old I-Ds in the datatracker -- Robert >=20 > - Replace I-Ds in proceedings with links to archive copy? >=20 > - Can the test process for the NomCom Tool be more comprehensive? >=20 > 8. AOB >=20 > Robert - some small SOWs for handling interim meetings management > and manual submission of IDs requests. On the cusp of being bid > out. >=20 > Kathleen - curious as to state of requests from IESG >=20 > Robert - =E2=80=9Cdiscuss box=E2=80=9D all fixed, in an upcoming bug = fix next week. >=20 >=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --Apple-Mail=_92BA1D32-5DF6-413E-9AA8-886B7BDEC56C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVdywPAAoJEK7rdBF357uoajwH/Ajqm0GlpTnwghr2LOWoYymY lnaZN9sFyy0yVyeK3DHS8fZ5iKGiJCOcCGXgRmvYiru/21SuPBSYKaf37Elo7tEp qHesVW/uEr4lSHUDt5MH7etom5WfG7YsYP2+z+bGSm5oi/W/PlDpJywgOSvN4DbF qhzp7yOx0kpzAZmTtpbLUVvmC+RrDptVIR9fy3geIzV5uIe33R8wc2KmI69OqQft 5L3IOrgSgAtbC/Omcp56k2T3vAOP0cuiwGzWSH3X524DFfWmKE06E5qaalxjQKvz lYAEs0anIVlYJ1Ddfd/lV6t5RdVSBeskfjsiZ5wcd/e08zQYqRQP4FK1wiqBbvY= =8r5c -----END PGP SIGNATURE----- --Apple-Mail=_92BA1D32-5DF6-413E-9AA8-886B7BDEC56C-- From nobody Tue Jun 9 11:20:07 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EA01B2E28 for ; Tue, 9 Jun 2015 11:20:05 -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 famXZBrpievM for ; Tue, 9 Jun 2015 11:20:04 -0700 (PDT) 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 BF9F11AC3C1 for ; Tue, 9 Jun 2015 11:20:04 -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 t59IK3tr046040 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 9 Jun 2015 13:20:04 -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: <55772E4E.9060008@nostrum.com> Date: Tue, 09 Jun 2015 13:19:58 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: IETF Tools Development Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TOOLS-DEVELOPMENT] Documentation for the I-D Archive and repository X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 18:20:06 -0000 All - following up on the conversation on today's call, here's a pointer to where the information about the repository and archive is written down. Let me know if you know of somewhere else this is also captured, or if there is a better place to keep this. RjS From nobody Wed Jun 17 08:55:11 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A414E1AD080 for ; Wed, 17 Jun 2015 08:55:10 -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 WaGygAy4DHAg for ; Wed, 17 Jun 2015 08:55:09 -0700 (PDT) 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 03A391AD34C for ; Wed, 17 Jun 2015 08:55:07 -0700 (PDT) Received: from unnumerable.local (mobile-166-173-059-154.mycingular.net [166.173.59.154]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5HFt58H066589 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 17 Jun 2015 10:55:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-059-154.mycingular.net [166.173.59.154] claimed to be unnumerable.local Message-ID: <55819854.7060409@nostrum.com> Date: Wed, 17 Jun 2015 10:55:00 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: IETF Tools Development References: <20150617153759.GA15534@pfrc.org> In-Reply-To: <20150617153759.GA15534@pfrc.org> X-Forwarded-Message-Id: <20150617153759.GA15534@pfrc.org> Content-Type: multipart/alternative; boundary="------------080900070901050501000406" Archived-At: Subject: [TOOLS-DEVELOPMENT] Fwd: Re: IETF 93 Scheduling Issues X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 15:55:10 -0000 This is a multi-part message in MIME format. --------------080900070901050501000406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Please note the tools request at the end. Does anyone have any grief with proceedings holding materials for groups that did not "meet" at the meeting? How should they be organized? (or is this something we already do that's not well used?) RjS -------- Forwarded Message -------- Subject: Re: IETF 93 Scheduling Issues Date: Wed, 17 Jun 2015 11:37:59 -0400 From: Jeffrey Haas To: Adrian Farrel CC: 'WG Chairs' On Tue, Jun 16, 2015 at 09:10:47AM +0100, Adrian Farrel wrote: > As always, it should come down to making proper use of face-to-face time for > discussions of thorny issues. I think that too much time is spent presenting > drafts that we could read in our own time, and a lot of discussion seems to be > simple questions that could have been raised in email after reading the draft. > That means that the meetings have become a convenience for the busy (an > executive summary rather than sitting and reading) and an indulgence for those > for whom typing an email is just too much effort. I've tried rather hard to keep BFD sessions pertinent to things that require f2f discussion. I'm not a supporter of "read a draft to the room in slide form". That said, even things intended to have some level of initial discussion don't always get any feedback so best intentions don't always come to fuition. One thing we do not do well though is permitting "virtual presentations" in the context of an IETF session. During one point where BFD did not meet, I had gotten update slides from the various work, consolidated them and tried to find a way to add them to the proceedings. We didn't support that at the time. So, request for the tools folk: Let us post to proceedings without having an actual meeting schedule. -- Jeff --------------080900070901050501000406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Please note the tools request at the end.

Does anyone have any grief with proceedings holding materials for groups that did not "meet" at the meeting?
How should they be organized? (or is this something we already do that's not well used?)

RjS


-------- Forwarded Message --------
Subject: Re: IETF 93 Scheduling Issues
Date: Wed, 17 Jun 2015 11:37:59 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Adrian Farrel <adrian@olddog.co.uk>
CC: 'WG Chairs' <wgchairs@ietf.org> 


On Tue, Jun 16, 2015 at 09:10:47AM +0100, Adrian Farrel wrote:
> As always, it should come down to making proper use of face-to-face time for
> discussions of thorny issues. I think that too much time is spent presenting
> drafts that we could read in our own time, and a lot of discussion seems to be
> simple questions that could have been raised in email after reading the draft.
> That means that the meetings have become a convenience for the busy (an
> executive summary rather than sitting and reading) and an indulgence for those
> for whom typing an email is just too much effort.

I've tried rather hard to keep BFD sessions pertinent to things that require
f2f discussion.  I'm not a supporter of "read a draft to the room in slide
form".  That said, even things intended to have some level of initial
discussion don't always get any feedback so best intentions don't always
come to fuition.

One thing we do not do well though is permitting "virtual presentations" in
the context of an IETF session.  During one point where BFD did not meet, I
had gotten update slides from the various work, consolidated them and tried
to find a way to add them to the proceedings.  We didn't support that at the
time.

So, request for the tools folk: Let us post to proceedings without having an
actual meeting schedule.  

-- Jeff


--------------080900070901050501000406-- From nobody Wed Jun 17 09:54:11 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29B41B2ACB for ; Wed, 17 Jun 2015 09:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f7WZjw_PEPx for ; Wed, 17 Jun 2015 09:54:07 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 48B3D1B2ACA for ; Wed, 17 Jun 2015 09:54:07 -0700 (PDT) Received: (qmail 8495 invoked by uid 0); 17 Jun 2015 16:54:05 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 17 Jun 2015 16:54:05 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id hUmL1q00o2SSUrH01UmPxN; Wed, 17 Jun 2015 10:46:29 -0600 X-Authority-Analysis: v=2.1 cv=O/iq4nNW c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=gZbpxnkM3yUA:10 a=Tg0nUI2_AAAA:8 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=389LV1QCwi7NAkAr61AA:9 a=IjsYOR4kzvDHQUpq:21 a=WAeEOWS6mL5p-z3V:21 a=pILNOxqGKmIA:10 a=Z80JlwQ0AAAA:8 a=GjkT4o1UFxlFmTOXEz8A:9 a=xXQNgK4O4RcnqzS5:21 a=l06Tn7lgujEThK21:21 a=TG9LQ4X99ryuwIds:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=ad4g75TTWTDK0xTYY7FADo+6MNdRJr6+Ky13JLlm+5k=; b=ON0Uy7I2QMvQRC6yBBwR2chfW8aaGaxV810cowSsWF1UwbKtKDX5kJkkDo0mcthWnDAUOHThv41GSKtdhbuqKgWWElbTzAq/49fcP7/CojbMptLbGvhdPWj3i3sZ0Cbz; Received: from box313.bluehost.com ([69.89.31.113]:52828 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z5Gb6-0007jL-55; Wed, 17 Jun 2015 10:53:56 -0600 Message-ID: <5581A61E.9070600@labn.net> Date: Wed, 17 Jun 2015 12:53:50 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Robert Sparks , IETF Tools Development References: <20150617153759.GA15534@pfrc.org> <55819854.7060409@nostrum.com> In-Reply-To: <55819854.7060409@nostrum.com> Content-Type: multipart/alternative; boundary="------------070302080903080308030802" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fwd: Re: IETF 93 Scheduling Issues X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 16:54:09 -0000 This is a multi-part message in MIME format. --------------070302080903080308030802 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit >From the technical standpoint: no. >From the process standpoint: I think having non-meeting material in the proceedings is an IESG call. -- I'll say this on the chairs list too. Lou On 6/17/2015 11:55 AM, Robert Sparks wrote: > Please note the tools request at the end. > > Does anyone have any grief with proceedings holding materials for > groups that did not "meet" at the meeting? > How should they be organized? (or is this something we already do > that's not well used?) > > RjS > > > -------- Forwarded Message -------- > Subject: Re: IETF 93 Scheduling Issues > Date: Wed, 17 Jun 2015 11:37:59 -0400 > From: Jeffrey Haas > To: Adrian Farrel > CC: 'WG Chairs' > > > > On Tue, Jun 16, 2015 at 09:10:47AM +0100, Adrian Farrel wrote: > > As always, it should come down to making proper use of face-to-face time for > > discussions of thorny issues. I think that too much time is spent presenting > > drafts that we could read in our own time, and a lot of discussion seems to be > > simple questions that could have been raised in email after reading the draft. > > That means that the meetings have become a convenience for the busy (an > > executive summary rather than sitting and reading) and an indulgence for those > > for whom typing an email is just too much effort. > > I've tried rather hard to keep BFD sessions pertinent to things that require > f2f discussion. I'm not a supporter of "read a draft to the room in slide > form". That said, even things intended to have some level of initial > discussion don't always get any feedback so best intentions don't always > come to fuition. > > One thing we do not do well though is permitting "virtual presentations" in > the context of an IETF session. During one point where BFD did not meet, I > had gotten update slides from the various work, consolidated them and tried > to find a way to add them to the proceedings. We didn't support that at the > time. > > So, request for the tools folk: Let us post to proceedings without having an > actual meeting schedule. > > -- Jeff > > > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --------------070302080903080308030802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit From the technical standpoint: no. 
From the process standpoint: I think having non-meeting material in the proceedings is an IESG call. -- I'll say this on the chairs list too.

Lou

On 6/17/2015 11:55 AM, Robert Sparks wrote:
Please note the tools request at the end.

Does anyone have any grief with proceedings holding materials for groups that did not "meet" at the meeting?
How should they be organized? (or is this something we already do that's not well used?)

RjS


-------- Forwarded Message --------
Subject: Re: IETF 93 Scheduling Issues
Date: Wed, 17 Jun 2015 11:37:59 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Adrian Farrel <adrian@olddog.co.uk>
CC: 'WG Chairs' <wgchairs@ietf.org> 


On Tue, Jun 16, 2015 at 09:10:47AM +0100, Adrian Farrel wrote:
> As always, it should come down to making proper use of face-to-face time for
> discussions of thorny issues. I think that too much time is spent presenting
> drafts that we could read in our own time, and a lot of discussion seems to be
> simple questions that could have been raised in email after reading the draft.
> That means that the meetings have become a convenience for the busy (an
> executive summary rather than sitting and reading) and an indulgence for those
> for whom typing an email is just too much effort.

I've tried rather hard to keep BFD sessions pertinent to things that require
f2f discussion.  I'm not a supporter of "read a draft to the room in slide
form".  That said, even things intended to have some level of initial
discussion don't always get any feedback so best intentions don't always
come to fuition.

One thing we do not do well though is permitting "virtual presentations" in
the context of an IETF session.  During one point where BFD did not meet, I
had gotten update slides from the various work, consolidated them and tried
to find a way to add them to the proceedings.  We didn't support that at the
time.

So, request for the tools folk: Let us post to proceedings without having an
actual meeting schedule.  

-- Jeff






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

--------------070302080903080308030802-- From nobody Wed Jun 17 17:35:40 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058471B2F4C for ; Wed, 17 Jun 2015 17:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 WjDOQW6WODGu for ; Wed, 17 Jun 2015 17:35:37 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 71D431B2F4B for ; Wed, 17 Jun 2015 17:35:37 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id B39719A404F; Wed, 17 Jun 2015 20:35:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id sU+tRE4Z0WXo; Wed, 17 Jun 2015 20:33:56 -0400 (EDT) Received: from [10.0.7.92] (unknown [201.234.152.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D17999A4062; Wed, 17 Jun 2015 20:34:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-157-1013925436 From: Russ Housley In-Reply-To: <55819854.7060409@nostrum.com> Date: Wed, 17 Jun 2015 20:34:18 -0400 Message-Id: <286BEF55-3D30-43FE-98A1-E0BA78598341@vigilsec.com> References: <20150617153759.GA15534@pfrc.org> <55819854.7060409@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] Fwd: Re: IETF 93 Scheduling Issues X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 00:35:40 -0000 --Apple-Mail-157-1013925436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think that the only time we post material for a WG that did not meet = is when they have had a virtual of face-to-face interim. Russ On Jun 17, 2015, at 11:55 AM, Robert Sparks wrote: > Please note the tools request at the end. >=20 > Does anyone have any grief with proceedings holding materials for = groups that did not "meet" at the meeting? > How should they be organized? (or is this something we already do = that's not well used?) >=20 > RjS >=20 >=20 > -------- Forwarded Message -------- > Subject: Re: IETF 93 Scheduling Issues > Date: Wed, 17 Jun 2015 11:37:59 -0400 > From: Jeffrey Haas > To: Adrian Farrel > CC: 'WG Chairs' >=20 > On Tue, Jun 16, 2015 at 09:10:47AM +0100, Adrian Farrel wrote: > > As always, it should come down to making proper use of face-to-face = time for > > discussions of thorny issues. I think that too much time is spent = presenting > > drafts that we could read in our own time, and a lot of discussion = seems to be > > simple questions that could have been raised in email after reading = the draft. > > That means that the meetings have become a convenience for the busy = (an > > executive summary rather than sitting and reading) and an indulgence = for those > > for whom typing an email is just too much effort. >=20 > I've tried rather hard to keep BFD sessions pertinent to things that = require > f2f discussion. I'm not a supporter of "read a draft to the room in = slide > form". That said, even things intended to have some level of initial > discussion don't always get any feedback so best intentions don't = always > come to fuition. >=20 > One thing we do not do well though is permitting "virtual = presentations" in > the context of an IETF session. During one point where BFD did not = meet, I > had gotten update slides from the various work, consolidated them and = tried > to find a way to add them to the proceedings. We didn't support that = at the > time. >=20 > So, request for the tools folk: Let us post to proceedings without = having an > actual meeting schedule. =20 >=20 > -- Jeff >=20 >=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --Apple-Mail-157-1013925436 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I think that the only time we post material for a WG that did not meet is when they have had a virtual of face-to-face interim.

Russ


On Jun 17, 2015, at 11:55 AM, Robert Sparks wrote:

Please note the tools request at the end.

Does anyone have any grief with proceedings holding materials for groups that did not "meet" at the meeting?
How should they be organized? (or is this something we already do that's not well used?)

RjS


-------- Forwarded Message --------
Subject: Re: IETF 93 Scheduling Issues
Date: Wed, 17 Jun 2015 11:37:59 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Adrian Farrel <adrian@olddog.co.uk>
CC: 'WG Chairs' <wgchairs@ietf.org> 


On Tue, Jun 16, 2015 at 09:10:47AM +0100, Adrian Farrel wrote:
> As always, it should come down to making proper use of face-to-face time for
> discussions of thorny issues. I think that too much time is spent presenting
> drafts that we could read in our own time, and a lot of discussion seems to be
> simple questions that could have been raised in email after reading the draft.
> That means that the meetings have become a convenience for the busy (an
> executive summary rather than sitting and reading) and an indulgence for those
> for whom typing an email is just too much effort.

I've tried rather hard to keep BFD sessions pertinent to things that require
f2f discussion.  I'm not a supporter of "read a draft to the room in slide
form".  That said, even things intended to have some level of initial
discussion don't always get any feedback so best intentions don't always
come to fuition.

One thing we do not do well though is permitting "virtual presentations" in
the context of an IETF session.  During one point where BFD did not meet, I
had gotten update slides from the various work, consolidated them and tried
to find a way to add them to the proceedings.  We didn't support that at the
time.

So, request for the tools folk: Let us post to proceedings without having an
actual meeting schedule.  

-- Jeff


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

--Apple-Mail-157-1013925436-- From nobody Fri Jun 26 12:18:41 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71AC1AC40B for ; Fri, 26 Jun 2015 12:18:39 -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 EhYoAVVaK4Gf for ; Fri, 26 Jun 2015 12:18:38 -0700 (PDT) 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 B6B9E1AC3EA for ; Fri, 26 Jun 2015 12:18:38 -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 t5QJIbMk063963 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 26 Jun 2015 14:18:37 -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: <558DA588.8050309@nostrum.com> Date: Fri, 26 Jun 2015 14:18:32 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: RFC Design Team , IETF Tools Development Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TOOLS-DEVELOPMENT] Update to the idnits SoW X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 19:18:40 -0000 During rfc-design team discussion (and development of the preptool draft), we identified several new things that idnits should do with xml2rfc v3 source documents. I've captured them at Change bars are on. Please give the new requirements careful review. The current versions of all the SoW are in that directory. RjS From nobody Sat Jun 27 08:45:41 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C2C1B2DD9 for ; Sat, 27 Jun 2015 08:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553] 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 eQEHcsjI5dSz for ; Sat, 27 Jun 2015 08:45:39 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 DA3DE1B2CD6 for ; Sat, 27 Jun 2015 08:45:39 -0700 (PDT) Received: from [10.20.30.101] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t5RFjb22099441 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Jun 2015 08:45:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: <558DA588.8050309@nostrum.com> Date: Sat, 27 Jun 2015 08:45:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2EDEA32D-FED7-481F-B8E3-12A8BDD2478B@vpnc.org> References: <558DA588.8050309@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.2098) Archived-At: Cc: RFC Design , IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] [rfc-design] Update to the idnits SoW X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 15:45:41 -0000 On Jun 26, 2015, at 12:18 PM, Robert Sparks = wrote: > During rfc-design team discussion (and development of the preptool = draft), we identified several new things that idnits should do with = xml2rfc v3 source documents. >=20 > I've captured them at > >=20 > Change bars are on. Please give the new requirements careful review. >=20 > The current versions of all the SoW are in that directory. A few notes: - I am pretty confused about the modes. The existence of "submission" = mode means that now some errors are only errors some of the time, which = makes them sound like warnings when they are not errors. Further, = "forgive" mode also seems to weaken some things. Why are some things be = errors only some of the time? When would that be valuable? To me, idnits = should clearly say "if you have X in your document, you cannot submit it = as a draft" and "if the document has X in it, it cannot become an RFC", = and everything else is a warning. - The text says "Other section headings can be searched for in a = tag with a
tag." but there is no = tag; I think you mean . - The "FQDN appears (other than www.ietf.org) not meeting = RFC2606/RFC6761 recommendations" has caused lots of problems in the = past, where authors have felt that they had to make all names be under = .example, even when that made differentiating two names difficult. I see = that this is just a warning, but it would be good if the warning message = said that exceptions can be made to make the document clearer. - I don't understand "A code-block is detected, but the block does not = contain a license declaration". How does idnits determine what is code? = (I suspect that this rule is a tarbaby that I ignored when it was = developed.) - "if the text was really a reference it should be in an tag" = seems wrong. Did you mean ? - "Document starts with PK or BM". I have no idea what those are. - What does section 3.3.2 mean? Are these for draft submission in = text-only format? If so, what are the other parts of 3.3 for? Hope this helps. --Paul Hoffman= From nobody Sun Jun 28 15:17:40 2015 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9534B1B2F7F for ; Sun, 28 Jun 2015 15:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 so4xx2ZZCahY for ; Sun, 28 Jun 2015 15:17:33 -0700 (PDT) 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 16D9C1B2F7E for ; Sun, 28 Jun 2015 15:17:33 -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 t5SMHWap048905 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Sun, 28 Jun 2015 17:17:32 -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: <55907277.9060202@nostrum.com> Date: Sun, 28 Jun 2015 17:17:27 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul Hoffman References: <558DA588.8050309@nostrum.com> <2EDEA32D-FED7-481F-B8E3-12A8BDD2478B@vpnc.org> In-Reply-To: <2EDEA32D-FED7-481F-B8E3-12A8BDD2478B@vpnc.org> Content-Type: multipart/alternative; boundary="------------000408000305050800050006" Archived-At: Cc: RFC Design , IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] [rfc-design] Update to the idnits SoW X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2015 22:17:36 -0000 This is a multi-part message in MIME format. --------------000408000305050800050006 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 6/27/15 10:45 AM, Paul Hoffman wrote: > On Jun 26, 2015, at 12:18 PM, Robert Sparks wrote: >> During rfc-design team discussion (and development of the preptool draft), we identified several new things that idnits should do with xml2rfc v3 source documents. >> >> I've captured them at >> >> >> Change bars are on. Please give the new requirements careful review. >> >> The current versions of all the SoW are in that directory. > A few notes: > > - I am pretty confused about the modes. The existence of "submission" mode means that now some errors are only errors some of the time, which makes them sound like warnings when they are not errors. Further, "forgive" mode also seems to weaken some things. Why are some things be errors only some of the time? When would that be valuable? To me, idnits should clearly say "if you have X in your document, you cannot submit it as a draft" and "if the document has X in it, it cannot become an RFC", and everything else is a warning. The tool is used in several different contexts. The "forgive checklist" mode was developed for the RPC, if I recall correctly. They run the tool in that mode at a few points while working on an RFC and they asked for several things to not be errors. Alice or Henrik might be able to provide even more insight. > > - The text says "Other section headings can be searched for in a tag with a
tag." but there is no tag; I think you mean . Thanks - that's a holdover from the first version of this sow which was done about the time hoffman-xml2rfc was at version 09. It would be good to look to see if there are other change we need to adjust to from that era. > > - The "FQDN appears (other than www.ietf.org) not meeting RFC2606/RFC6761 recommendations" has caused lots of problems in the past, where authors have felt that they had to make all names be under .example, even when that made differentiating two names difficult. I see that this is just a warning, but it would be good if the warning message said that exceptions can be made to make the document clearer. > > - I don't understand "A code-block is detected, but the block does not contain a license declaration". How does idnits determine what is code? (I suspect that this rule is a tarbaby that I ignored when it was developed.) The current tool looks for and in the text. See section 4.b of http://trustee.ietf.org/license-info/IETF-TLP-5.pdf The new tool will have new and more semantically informative things to look for, at least when processing xml input. > > - "if the text was really a reference it should be in an tag" seems wrong. Did you mean ? Probably. > > - "Document starts with PK or BM". I have no idea what those are. These are the strange things that you find when you start looking under the rocks in an organically grown tool. You would probably find reading through https://tools.ietf.org/tools/idnits/idnits-v2.13.02 helpful. In this particular case, you're looking for: if (has_pk_mark) { comment("The first octets (the first characters of the first line) of this " \ "draft are 'PK', which can make Internet Explorer erroneously think " \ "that it is a zip file. It is recommended that you change this, for " \ "instance by inserting a blank line before the line starting with 'PK'.") } if (has_bm_mark) { comment("The first octets (the first characters of the first line) of this " \ "draft are 'BM', which can make the draft submission tool erroneously think " \ "that it is an image .bmp file. It is recommended that you change this, for " \ "instance by inserting a blank line before the line starting with 'BM'.") } You can also grep for "option_checklistwarn" for more insight into the forgive-checklist mode. > > - What does section 3.3.2 mean? Are these for draft submission in text-only format? All of section 3.3 is for processing text-only documents. 3.3.2 is for text-only documents that are Internet Drafts, and not text documents that are being prepared for publication as RFCs. (This tool could well be finished before others, and used during pre- transition, while we're still producing text RFCs. And, if it all falls apart and we continue working with text for longer than we plan, this rewrite of idnits is still highly desirable). > If so, what are the other parts of 3.3 for? > > Hope this helps. > > --Paul Hoffman --------------000408000305050800050006 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

On 6/27/15 10:45 AM, Paul Hoffman wrote:
On Jun 26, 2015, at 12:18 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

During rfc-design team discussion (and development of the preptool draft), we identified several new things that idnits should do with xml2rfc v3 source documents.

I've captured them at
<http://www.nostrum.com/~rjsparks/rfced/idnits-02.pdf>

Change bars are on. Please give the new requirements careful review.

The current versions of all the SoW are in that directory.

A few notes:

- I am pretty confused about the modes. The existence of "submission" mode means that now some errors are only errors some of the time, which makes them sound like warnings when they are not errors. Further, "forgive" mode also seems to weaken some things. Why are some things be errors only some of the time? When would that be valuable? To me, idnits should clearly say "if you have X in your document, you cannot submit it as a draft" and "if the document has X in it, it cannot become an RFC", and everything else is a warning.
The tool is used in several different contexts. The "forgive checklist" mode was developed for the RPC, if I recall correctly. They run the tool in that mode at a few points while working on an RFC and they asked for several things to not be errors. Alice or Henrik might be able to provide even more insight.


- The text says "Other section headings can be searched for in a <titleelement> tag with a <section> tag." but there is no <titleelement> tag; I think you mean <name>.
Thanks - that's a holdover from the first version of this sow which was done about the time hoffman-xml2rfc was at version 09.
It would be good to look to see if there are other change we need to adjust to from that era.


- The "FQDN appears (other than www.ietf.org) not meeting RFC2606/RFC6761 recommendations" has caused lots of problems in the past, where authors have felt that they had to make all names be under .example, even when that made differentiating two names difficult. I see that this is just a warning, but it would be good if the warning message said that exceptions can be made to make the document clearer.

- I don't understand "A code-block is detected, but the block does not contain a license declaration". How does idnits determine what is code? (I suspect that this rule is a tarbaby that I ignored when it was developed.)
The current tool looks for <CODE BEGINS> and <CODE ENDS> in the text.
See section 4.b of http://trustee.ietf.org/license-info/IETF-TLP-5.pdf
The new tool will have new and more semantically informative things to look for, at least when processing xml input.

- "if the text was really a reference it should be in an <eref> tag" seems wrong. Did you mean <xref>?
Probably.

- "Document starts with PK or BM". I have no idea what those are.
These are the strange things that you find when you start looking under the rocks in an organically grown tool.
You would probably find reading through https://tools.ietf.org/tools/idnits/idnits-v2.13.02 helpful. In this particular case, you're looking for:
		if (has_pk_mark) { comment("The first octets (the first characters of the first line) of this " \
					   "draft are 'PK', which can make Internet Explorer erroneously think " \
					   "that it is a zip file.  It is recommended that you change this, for " \
					   "instance by inserting a blank line before the line starting with 'PK'.") }

		if (has_bm_mark) { comment("The first octets (the first characters of the first line) of this " \
					   "draft are 'BM', which can make the draft submission tool erroneously think " \
					   "that it is an image .bmp file.  It is recommended that you change this, for " \
					   "instance by inserting a blank line before the line starting with 'BM'.") }
You can also grep for "option_checklistwarn" for more insight into the forgive-checklist mode.


- What does section 3.3.2 mean? Are these for draft submission in text-only format?
All of section 3.3 is for processing text-only documents.
3.3.2 is for text-only documents that are Internet Drafts, and not text documents that are being prepared for publication as RFCs.
(This tool could well be finished before others, and used during pre- transition, while we're still producing text RFCs.
And, if it all falls apart and we continue working with text for longer than we plan, this rewrite of idnits is still highly desirable).

 If so, what are the other parts of 3.3 for?

Hope this helps.

--Paul Hoffman

--------------000408000305050800050006--