From tools-team-bounces@ietf.org Mon Jun 05 13:02:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnITH-0007nu-HI; Mon, 05 Jun 2006 13:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnITG-0007nW-7R; Mon, 05 Jun 2006 13:02:30 -0400 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnITD-0004FR-QG; Mon, 05 Jun 2006 13:02:30 -0400 Received: from pail.measurement-factory.com (c-24-8-143-105.hsd1.co.comcast.net [24.8.143.105]) by measurement-factory.com (8.13.4/8.13.4) with ESMTP id k55H2Ped058232; Mon, 5 Jun 2006 11:02:26 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) From: Alex Rousskov To: Internet-Drafts@ietf.org Content-Type: multipart/mixed; boundary="=-N6bHxjtOayXb0IdaC3/g" Date: Mon, 05 Jun 2006 11:02:15 -0600 Message-Id: <1149526935.71335.4.camel@pail.measurement-factory.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port X-Spam-Score: 0.1 (/) X-Scan-Signature: c075d775af780178ad8663695edfd43a Cc: tools-team@ietf.org Subject: [Tools-team] Request To Publish: draft-ietf-tools-draft-info-04 X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tools-team-bounces@ietf.org --=-N6bHxjtOayXb0IdaC3/g Content-Type: text/plain Content-Transfer-Encoding: 7bit Please post the attached draft-ietf-tools-draft-info-04.txt file as a Tools team Internet-Draft. Thank you, Alex. --=-N6bHxjtOayXb0IdaC3/g Content-Disposition: attachment; filename=draft-ietf-tools-draft-info-04.txt Content-Type: text/plain; name=draft-ietf-tools-draft-info-04.txt; charset=us-ascii Content-Transfer-Encoding: 7bit Tools team A. Rousskov Internet-Draft The Measurement Factory Expires: December 7, 2006 June 5, 2006 Requirements for Providing Information on IETF Internet-Drafts draft-ietf-tools-draft-info-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies what information IETF should provide about an IETF Internet-Draft. Information requirements cover submitted, posted, published, expired, and other personal or Working Group drafts. Rousskov Expires December 7, 2006 [Page 1] Internet-Draft Draft Information Requirements June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. State of this draft version . . . . . . . . . . . . . . . . . 3 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4 5. Status quo . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Draft information . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Draft identifier . . . . . . . . . . . . . . . . . . . . . 5 6.2. Draft metadata . . . . . . . . . . . . . . . . . . . . . . 6 6.2.1. Status . . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. Draft versions . . . . . . . . . . . . . . . . . . . . . . 7 6.4. Change history . . . . . . . . . . . . . . . . . . . . . . 7 6.5. Draft events . . . . . . . . . . . . . . . . . . . . . . . 7 7. Draft Version . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Version identifier . . . . . . . . . . . . . . . . . . . . 8 7.2. Version metadata . . . . . . . . . . . . . . . . . . . . . 8 7.2.1. Version number . . . . . . . . . . . . . . . . . . . . 8 7.2.2. Posting date . . . . . . . . . . . . . . . . . . . . . 9 7.2.3. Nits . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3. Primary version format . . . . . . . . . . . . . . . . . . 9 7.4. Version formats . . . . . . . . . . . . . . . . . . . . . 10 8. Format information . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Format metadata . . . . . . . . . . . . . . . . . . . . . 10 8.2. Format data . . . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Comparison with current procedures . . . . . . . . . 11 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 11 12. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Rousskov Expires December 7, 2006 [Page 2] Internet-Draft Draft Information Requirements June 2006 1. Introduction Public Internet-Drafts are primary means of structured communication within IETF. The information that IETF currently provides about any given draft is decentralized and often insufficient to facilitate on- going draft review and use by IETFers and 3rd parties. The IETF Tools team recommends creation of a single, authoritative, and comprehensive IETF source for draft information. This document specifies what information IETF should provide about a draft and, to a limited extent, how that information needs to be provided. Most, if not all, requirements in this document are inspired by existing sources of draft information, both on official IETF web sites and sites administered outside of IETF. 2. State of this draft version This draft version is meant to contain a complete list of draft information items. Some items need more documentation and supplementary sections are missing content. Tools team review has started, but this version may not represent Tools team consensus. The text has not been polished. Please review this draft. Did we miss any draft information items you want IETF to provide? Should we remove some of the items? We are also looking for additional pointers to resources providing useful draft information. Please post your comments on tools-discuss@ietf.org mailing list or email them directly to the author. RFC Editor Note: Please remove this section for the final publication of the document. It has been inspired by draft-rousskov-newtrk-id-state and related NEWTRK WG discussions. 3. Scope The document scope is a single Internet-Draft, including multiple versions and formats of the same draft. The requirements cover submitted, posted, published, expired, and unknown personal or Working Group drafts. The interfaces required to locate a draft or correlate information about multiple drafts are out of scope. Rousskov Expires December 7, 2006 [Page 3] Internet-Draft Draft Information Requirements June 2006 4. Notation and Terminology This sections provides definitions for terms which are frequently used in this document. posted draft: A draft accepted into the public IETF draft repository and, hence, publicly available on the IETF web site. draft version: A meant-to-be-public snapshot of an Internet-Draft with a meant-to-be-unique version number. Also known as a "draft revision". draft format: Any draft source or presentation format, including original and preprocessed XML, original or generated plain text as well as PDF, PostScript, and HTML formats. Also known as a "version format". primary format: The first available draft format from the following list: plain text, PDF, PostScript, or XML. WG draft: A draft under a working group control. This document does not specify how to identify WG drafts, but most WG drafts have identifier (a.k.a. filename) that starts with "draft-ietf-". individual draft: A draft other than a WG draft. Normative requirements in this document are English phrases ending with an "(Rnnn/s)" mark, where "nnn" is a unique requirement number, and "s" is a single letter code ("a", "b", or "c") specifying the implementation stage for the requirement. . [[XXX1: Normative requirements have not been identified yet. --Alex]] This document does not specify how the implementation must obtain necessary draft information and does not require specific information rendering techniques. However, implementation hints or examples are often useful. To avoid mix up with normative requirements, such hints and examples are marked with a "Hint:" prefix. Implementation hints do not carry any normative force, and a different implementation may be the best choice. 5. Status quo At the time of writing, all of the draft information pieces described in this document are already available in one form or another. Here is an incomplete list of resources providing draft information. Note that provided information outside of this draft scope is not mentioned here. Rousskov Expires December 7, 2006 [Page 4] Internet-Draft Draft Information Requirements June 2006 o IETF "Internet-Drafts Database Interface" [1]: Provides draft title, status, state, intended RFC category, RFC number, related documents, abstract, author names and emails. Format: HTML. o IETF "Internet-Drafts Tracker" [2]: Provides draft name, version, status, state, shepherding AD name, modification date, WG name, and IESG discussion details. Format: HTML. o IETF "list of current and expired drafts" [3]: Provides draft name, version, date, status. Format: tab-separated text. o IETF "index of active drafts" [4]: Provides title, authors, date, name and WG for active drafts. Format: Free-form text. o IETF "abstracts from active drafts" [5]: Provides title, authors, date, name, abstract and WG for active drafts. Format: Free-form text. o Henrik Levkowetz "Workgroup Status Pages" [6]: Provides draft name, date, all draft versions, diffs, nits, various draft formats, and last call information. Format: XHTML. o Potaroo Internet Drafts Repository [7]: Provides draft name, date, author names, WG name, abstract. Includes expired drafts. Format: HTML. 6. Draft information The following information must be available about a given draft: o draft identifier (Section 6.1) o draft meta-data (Section 6.2) o available draft versions (Section 6.3) o change history (Section 6.4) o events (Section 6.5) [[XXX5: We need A defined XML schema in some form (Relax-NG, by example, or whatever) in which the information defined here has to be provided. --Henrik]] 6.1. Draft identifier Draft identifier is a string that uniquely identifies any IETF draft Rousskov Expires December 7, 2006 [Page 5] Internet-Draft Draft Information Requirements June 2006 regardless of its version or status. At the time of writing, draft name can be used as an identifier, but implementations must not rely on that being the case. For example, future implementations may be able to keep the same identifier for a draft that changes ownership from individual to WG (assuming IETF decides that ownership changes do not create a new draft and, hence, a new internal identifier). 6.2. Draft metadata Draft metadata depends, in part, on draft status and includes the following items: o title o abstract o authors information o WG name o draft status (Section 6.2.1) o IESG states (for active and expired drafts) o IESG draft discussion information o published document information such as the publication date and version location(s) (for published drafts) o email address for draft discussion and comments o "obsoletes X", "updates X", "renamed to X", or "replaced by X" statements where "X" is a draft, RFC, or another document. o IPR category, including a "custom" category for IPR statements that are not defined by IETF. Draft metadata applies to the draft as a whole rather than a specific draft version. Nevertheless, it is based on the latest draft version and, hence, may change with draft revisions. For example, the title and the abstract may be extracted from the latest draft version. All draft metadata must be available in format(s) suitable for human consumption and in XML format. The following metadata is meant to be extracted, at some processing Rousskov Expires December 7, 2006 [Page 6] Internet-Draft Draft Information Requirements June 2006 stage, from the latest draft version: creation date, expiration date, IPR category. This list is not exhaustive. 6.2.1. Status A draft status is either "active", "expired", "published", "replaced", or "withdrawn". The status determines a subset of available draft metadata. The status also affects the availability of draft text and possibility of future text revisions. An active draft can be in one or more states related to IESG review activity. These states are not documented here, but implementations must provide this information using the current state list and state definitions maintained by IESG. Published document information (e.g., an RFC number) is provided for published drafts. Replacement information (e.g., new draft name) is provided for replaced drafts. [[XXX6: Should we define exactly what extra info is provided for published and replaced drafts? --Alex]] 6.3. Draft versions Each draft has at least one draft version associated with it. Draft information includes a list of all draft versions, including the expired ones. This index allows the user to assess draft revision activity and to access information specific to any version of a given draft (see Section 7). It also allows to determine the latest draft version. 6.4. Change history Change history provides information about the difference between any two versions of a given draft. That information includes the difference in draft version metadata and in draft version content. Change history may be precomputed or generated runtime, possibly depending on the versions being compared. For example, the implementation may assume that most users would be interested in changes between sequential versions and precomputed that while providing runtime-generated differences between arbitrary two versions. 6.5. Draft events Draft events information includes a list of all issued IETF events associated with the draft. This document does not define an IETF event interface, but typical entries might include "new draft version available" and "WG last call issued" with such details as "event Rousskov Expires December 7, 2006 [Page 7] Internet-Draft Draft Information Requirements June 2006 time", "event originator", and "informal event comments". 7. Draft Version For each available draft version, the following information should be provided: o version identifier (Section 7.1) o version meta-data (Section 7.2) o primary version format (Section 7.3) o all available version formats (Section 7.4) 7.1. Version identifier Draft version identifier is a non-negative integer number that uniquely identifies any draft version of a given draft. Version identifier values must increase by one with every new draft version posted. At the time of writing, draft version number can be used as an identifier, but implementations must not rely on that being the case. For example, future implementations may be able to keep incrementing version identifier when a draft changes ownership from individual to WG. 7.2. Version metadata Draft version metadata includes the following items: o version number (Section 7.2.1) o posting date (Section 7.2.2) o nits (Section 7.2.3) 7.2.1. Version number For a given draft filename, draft version numbers start with zero and increase by one with every new version. Single-digit draft version numbers are usually left-padded with "0" when rendered. The IETF infrastructure may have a limit on the number of draft versions, but that limit may change with time. The difference between version number and version identifier is that Rousskov Expires December 7, 2006 [Page 8] Internet-Draft Draft Information Requirements June 2006 the former is specific to a given draft filename. The version identifier may, in theory, span multiple draft filenames, tracking revisions of the "same" draft across ownership transfers and other events that may change the draft filename. 7.2.2. Posting date Draft version posting date reports the calendar date when the draft version was first accepted into the public IETF draft repository. The date may also contain the time-of-day of the posting. 7.2.3. Nits Draft version nits is a set of auto-detected violations of IETF policies related to draft content and format. Until nits reporting is standardized, only the number of auto-detected violations may be meaningful for automated processing; the meaning and perceived severity of auto-detected violations is meant for human consumption only. Nits are not expected to be human-editable. Errors in auto-detection should be handled by fixing nits-generating tools. Omissions may be handled by manually submitting comments on the draft. Nits must contain information about the tool(s) that were used to generate them, including the version and configuration of each tool. The intent is to make it straightforward for authors and others to rerun the nits check after an attempt to fix violations in a private copy. If the nits-generating tool distinguishes violation severity levels (e.g., errors versus warnings), and different level nits are included in metadata, then the severity distinction should be reflected in the metadata. [[XXX12: Nits are the result of applying external rules on the draft presentation format, and the external rules may change during the lifetime of a version. --Henrik]] [[XXX13: On the other hand, mentioning the version of the nits tool used and perhaps providing a user with a way to regenerate/refresh nits would be useful. We should make nits violations visible to encourage folks to fix violations. --Alex]] 7.3. Primary version format Primary draft version format is a format identifier (see Section 8.1) that specifies which of the version formats should be used by default when presenting the draft to the reader. For the vast majority of Rousskov Expires December 7, 2006 [Page 9] Internet-Draft Draft Information Requirements June 2006 IETF drafts, "TXT" will be the primary format. 7.4. Version formats A set of format identifiers (see Section 8.1) representing all available draft version formats. It is possible for the set of available formats for a given draft version to change (e.g., if IETF converts old plain text drafts into XML, making both formats available). If the set changes, the draft metadata must be updated as a part of the change. 8. Format information 8.1. Format metadata Draft version format metadata includes the following items: o format identifier (TXT, HTML, PDF, or PS) o format MIME type o format size o format-specific info (e.g., number of pages for text formats or PDF-specific nits) [[XXX9: Should we standardize format IDs or will they depend on the draft information encoding mechanism? For example, Atom draft event feeds may use format IDs different from those used by the IETF draft repository. --Alex]] 8.2. Format data Draft version format data is the content (a.k.a., "text") of the draft version, in the corresponding format. 9. Security Considerations Draft information covered in this document does not contain security- sensitive elements. However, drafts may have secret or private information associated with them (e.g., some IESG discussions and comments may be private). Implementors must be careful to protect such information from being exposed by public metadata renders. [[XXX14: Is this actually true? Can there be secret IESG notes or other protected information associated with a draft? --Alex]] Rousskov Expires December 7, 2006 [Page 10] Internet-Draft Draft Information Requirements June 2006 Draft information may be collected from many places. The process of information collection and formatting may be resource-consuming. Care must be taken to prevent this process from overloading the machines it uses, especially if some information is extracted and formatted dynamically (at the time of the request for that information). 10. IANA Considerations None. [[XXX11: If we standardize format IDs (see XXX9), will IANA have to register them? --Alex]] 11. Compliance TBD. Appendix A. Comparison with current procedures This section summarizes major differences between information currently provided by IETF and what is being proposed, including violations of the current IETF rules. o Currently, IETF provides only the latest draft version. This document requires providing all unexpired versions. This change allows to maintain a change history useful for draft review and discussion. The change does not seem to contradict written IETF rules and principles. If an experiment with providing unexpired but obsolete versions does not cause significant problems, the IETF rules might be modified to also provide all draft versions for unexpired drafts and, later, all draft versions ever posted. Appendix B. Acknowledgments The author gratefully acknowledges the contributions of Henrik Levkowetz. Special thanks to Marshall Rose for his xml2rfc tool. Appendix C. Change log RFC Editor Note: This section is to be removed during the final publication of the document. Rousskov Expires December 7, 2006 [Page 11] Internet-Draft Draft Information Requirements June 2006 Internal WG revision control ID: $Id: draft-info.xml,v 1.8 2006/06/05 16:58:42 rousskov Exp $ version 04 * Added two security threats to the Security Considerations section. * Added "IESG draft discussion information" to the draft meta- information list (Henrik Levkowetz). * Added "updates X" to the possible draft meta-data statements (Henrik Levkowetz). * Explicitly included draft publication date and draft location (e.g., document retrieval URL) in "draft publication information". * Explicitly listed metadata which is meant to be extracted (Henrik Levkowetz). * Do not imply that an expired draft may have an IESG review stage. Being under IESG consideration now prevents a draft from expiring (Henrik Levkowetz). * Polished draft [version] format definition. * Resolved XXX4: avoid giving a precise WG draft definition until one is needed. * Resolved XXX7: Nits must contain info about nit generation tool, for re-checking purposes (Henrik Levkowetz). * Resolved XXX8: If nit generation tool distinguishes errors from warnings, and both are included in metadata, then the distinction must be present in metadata as well. * Resolved XXX10: Acknowledged that available formats might change for a given draft version and required the metadata to be updated if they change. * Added XXX12: Discuss whether to include nits summary (Henrik Levkowetz and Alex). Rousskov Expires December 7, 2006 [Page 12] Internet-Draft Draft Information Requirements June 2006 version 03 * Wrote the "Version metadata" section. * Deleted the "Email interface" and "Implementation stages" sections as they were empty and may not be needed. * Updated IPR claims to match the RFC 3978 template. version 02 * Resolved XXX2: this document will have its own set of term definitions, even though some may duplicate definitions in other Tools documents. (Henrik Levkowetz) * Added more IETF draft information sources and updated Henrik's' sources (Henrik Levkowetz) * Applied Henrik Levkowetz' review comments. version 01 * Added missing draft information pieces and claimed that this version lists all pieces we want to provide. Many items still lack details. * Separated draft information pieces into draft/version/format layers. * Added "Status quo" section: Documented what draft information is currently available and listed a few sites providing that information. More popular sites needed. version 00 * Initial version. 12. Normative References [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005. [1] [2] [3] Rousskov Expires December 7, 2006 [Page 13] Internet-Draft Draft Information Requirements June 2006 [4] [5] [6] [7] Rousskov Expires December 7, 2006 [Page 14] Internet-Draft Draft Information Requirements June 2006 Author's Address Alex Rousskov The Measurement Factory Email: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/ Rousskov Expires December 7, 2006 [Page 15] Internet-Draft Draft Information Requirements June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rousskov Expires December 7, 2006 [Page 16] --=-N6bHxjtOayXb0IdaC3/g Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team --=-N6bHxjtOayXb0IdaC3/g-- From tools-team-bounces@ietf.org Wed Jun 14 10:06:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqW0p-0007oR-OU; Wed, 14 Jun 2006 10:06:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqW0o-0007nb-77 for tools-team@ietf.org; Wed, 14 Jun 2006 10:06:26 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqW0m-00072j-P9 for tools-team@ietf.org; Wed, 14 Jun 2006 10:06:26 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k5EE6Epq027339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jun 2006 17:06:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k5EE6DhB011839; Wed, 14 Jun 2006 17:06:13 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17552.6101.272501.637417@fireball.kivinen.iki.fi> Date: Wed, 14 Jun 2006 17:06:13 +0300 From: Tero Kivinen To: Henrik Levkowetz Subject: [Tools-team] Minutes from the 31 May 2006 Teleconference In-Reply-To: <447DC2AB.7030804@levkowetz.com> References: <447DC2AB.7030804@levkowetz.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Tools-team X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tools-team-bounces@ietf.org Henrik Levkowetz writes: > 6. Next meeting: > > Teleconference Wednesday 14th June, 16:00 GMT (same local time > as today). Are we going to have the teleconference today (i.e. in 2 hours)? -- kivinen@safenet-inc.com _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team From tools-team-bounces@ietf.org Wed Jun 14 11:35:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXOn-0006ck-7r; Wed, 14 Jun 2006 11:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXOm-0006cf-Jg for tools-team@ietf.org; Wed, 14 Jun 2006 11:35:16 -0400 Received: from av7-1-sn3.vrr.skanova.net ([81.228.9.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXOl-0004RV-Am for tools-team@ietf.org; Wed, 14 Jun 2006 11:35:16 -0400 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 2695F38279; Wed, 14 Jun 2006 17:09:10 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 1785838069; Wed, 14 Jun 2006 17:09:10 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 65EB537E42; Wed, 14 Jun 2006 17:35:14 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FqXOj-00083q-2u; Wed, 14 Jun 2006 17:35:13 +0200 Message-ID: <44902CB0.9060704@levkowetz.com> Date: Wed, 14 Jun 2006 17:35:12 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Tools-team] Minutes from the 31 May 2006 Teleconference References: <447DC2AB.7030804@levkowetz.com> <17552.6101.272501.637417@fireball.kivinen.iki.fi> In-Reply-To: <17552.6101.272501.637417@fireball.kivinen.iki.fi> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Tools-team X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0021899418==" Errors-To: tools-team-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0021899418== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5630E1FF2EF2671D87988B75" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5630E1FF2EF2671D87988B75 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oops - yes, this is my intention, but it's been one of these days! I'll send the agenda now. Henrik on 2006-06-14 16:06 Tero Kivinen said the following: > Henrik Levkowetz writes: >> 6. Next meeting: >>=20 >> Teleconference Wednesday 14th June, 16:00 GMT (same local time >> as today). >=20 > Are we going to have the teleconference today (i.e. in 2 hours)? --------------enig5630E1FF2EF2671D87988B75 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEkCyweVhrtTJkXCMRAjn+AKDSbXUxsYImUR+eE4Z4IeVnwQUAZQCghl/5 FasfLByjBhJcKzH/eOKVrO4= =ohMp -----END PGP SIGNATURE----- --------------enig5630E1FF2EF2671D87988B75-- --===============0021899418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team --===============0021899418==-- From tools-team-bounces@ietf.org Wed Jun 14 11:36:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXPs-0006g5-GB; Wed, 14 Jun 2006 11:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXPr-0006g0-Pj for tools-team@ietf.org; Wed, 14 Jun 2006 11:36:23 -0400 Received: from av11-1-sn2.hy.skanova.net ([81.228.8.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXPq-0004Wa-El for tools-team@ietf.org; Wed, 14 Jun 2006 11:36:23 -0400 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 9A112385F5; Wed, 14 Jun 2006 17:36:21 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 8AEF7382B9 for ; Wed, 14 Jun 2006 17:36:21 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 8000737E4E for ; Wed, 14 Jun 2006 17:36:21 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FqXPp-0008A5-8y; Wed, 14 Jun 2006 17:36:21 +0200 Message-ID: <44902CF5.4030606@levkowetz.com> Date: Wed, 14 Jun 2006 17:36:21 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Tools-team X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Tools-team] Agenda for the 14 June 2006 Teleconference X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tools-team-bounces@ietf.org Hi, Here is the proposed agenda for today's call. ------------------------------------------------------------------------ 1. Agenda bashing and comments on previous minutes 2. Status review * Dashboard - Henrik * Issue trackers, Wiki - Henrik * Review team support tool - Tero * Draft info draft - Alex * Meta-information schema - Stas 3. Tracker extension specification draft-ietf-proto-wgchair-tracker-ext draft-ietf-proto-iab-irtf-tracker-ext 4. Google Summer of Code info 5. Any other business 6. Next meeting: Teleconference Wednesday 28th of June, 16:00 GMT (same local time as today). ------------------------------------------------------------------------ Connection details: To join the call, dial +1-734-615-7474 and enter PIN 0151989. One can also join the call by dialling: sip:session_0151989@edial.internet2.edu on a SIP-enabled voice communications client. If the SIP client cannot dial URLs, you can have the conference system call you if you have the sip URL for your phone. Go to https://edial.internet2.edu/call/0151989 and type in the URL to your phone, and follow the directions. _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team From tools-team-bounces@ietf.org Wed Jun 14 13:13:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYvv-0000aA-6W; Wed, 14 Jun 2006 13:13:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYvt-0000XL-RE for tools-team@ietf.org; Wed, 14 Jun 2006 13:13:33 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqYh5-0004km-3a for tools-team@ietf.org; Wed, 14 Jun 2006 12:58:16 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k5EGw5go001220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jun 2006 19:58:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k5EGw52M020239; Wed, 14 Jun 2006 19:58:05 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17552.16412.516987.746408@fireball.kivinen.iki.fi> Date: Wed, 14 Jun 2006 19:58:04 +0300 From: Tero Kivinen To: Henrik Levkowetz Subject: [Tools-team] Agenda for the 14 June 2006 Teleconference In-Reply-To: <44902CF5.4030606@levkowetz.com> References: <44902CF5.4030606@levkowetz.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 10 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Tools-team X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tools-team-bounces@ietf.org Henrik Levkowetz writes: > 2. Status review > > * Dashboard > - Henrik Some comments about loginmgr. 1) That login manager really needs to require TLS protection, i.e mandate that both the forms and the posts are always using TLS. 2) The URL for changing password should only work exactly once, not for 24 hours. The problem with 24 hours is that if someone manages to get the URL later from my mailbox or some other place he can change my password after I changed it. If it works exactly once, either I will get error that password has already been changed using the URL (i.e. I know there was attacker who stole my URL) or the attacker cannot change my password after I have successfully changed it. Perhaps storing the used auth sha1sum to some directory and checking that it cannot be there before continuing. -- kivinen@safenet-inc.com _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team From tools-team-bounces@ietf.org Wed Jun 14 13:15:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYxP-0001Xz-Jy; Wed, 14 Jun 2006 13:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYvt-0000Qd-1K for tools-team@ietf.org; Wed, 14 Jun 2006 13:13:33 -0400 Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqYiT-0004vS-60 for tools-team@ietf.org; Wed, 14 Jun 2006 12:59:43 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id EF7C738176; Wed, 14 Jun 2006 18:59:35 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E1A5E37EC1 for ; Wed, 14 Jun 2006 18:59:35 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id CE7B437E44 for ; Wed, 14 Jun 2006 18:59:35 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FqYiN-0002pY-2K; Wed, 14 Jun 2006 18:59:35 +0200 Message-ID: <44904076.1090903@levkowetz.com> Date: Wed, 14 Jun 2006 18:59:34 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Tools-team X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.6 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [Tools-team] Minutes from the 14 June 2006 Teleconference X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tools-team-bounces@ietf.org Hi, Here are the minutes from today's call. ------------------------------------------------------------------------ 0. Present: Alex, Stas, Tero, Henrik, Bill 1. Agenda bashing and comments on previous minutes Nothing 2. Status review * Dashboard - Henrik Some preparatory work done in connection with the event notification engine, more work scheduled after the -0x draft submission deadline. * Issue trackers, Wiki - Henrik The user-id and password automation is in place as a new tool which is unimaginatively called loginmgr; the overview page for the tool is here: http://www1.tools.ietf.org/tools/loginmgr/ and the page you go to in order to get a user ID, or change your password, is here: http://www1.tools.ietf.org/tools/loginmgr/newlogin The 401 error page also displays a link to the newlogin page. With this in place, I expect to roll out wiki+issue trackers (based on Trac) for all working groups within a week or so, and notify the working group chairs about this. * Review team support tool - Tero Have some progress on that - have tried to get the secdir secretary to give comments, but he's been pretty busy. You can check it out here: http://ietf-tools-test.kivinen.iki.fi:2080/ * Draft info draft - Alex New version out now, there are about 10 XXX that need to be fixed - no major ones, except there's one about having a schema for all fields - but I see it's on the agenda that Stas is working on this, so maybe there should be a reference to his work. Please review and comment on the draft: http://tools.ietf.org/html/draft-ietf-tools-draft-info * Meta-information schema - Stas Have not worked on this yet. Busy with Google Summer of Code. 3. Tracker extension specification draft-ietf-proto-wgchair-tracker-ext draft-ietf-proto-iab-irtf-tracker-ext Bill: Concerned about overlap between IESG states and WG states. They probably should be separate states, so that the WG can record their progress on the document without disturbing the IESG state, which might be 'New revision needed'. This also goes further than the IESG/WG split - similar reasoning applies to the possible states which involves the RFC-Editor and IANA. Alex: Could this be modelled as tags instead of states - where you could have many parallel tags, which can co- exist - in contrast with states, where you can only be in a particular state, strictly speaking. Henrik: I'll revise the document along these lines. (Some discussion around the complexity of the IESG state machine) Bill: I think the tags idea is worth exploring, but there are some parts of the workflow which we've tried to capture in the states. But some substates might be better expressed as tag. Definitely worth exploring. 4. Google Summer of Code info The project is to build a notification engine, and expect to have an alpha version online for testing within a week, approximately. Bill: Interesting. I could maybe feed some events into this from my tracker extracted data, too... 5. Any other business Nothing 6. Next meeting: Teleconference Wednesday 28th of June, 16:00 GMT (same local time as today). ------------------------------------------------------------------------ Connection details: To join the call, dial +1-734-615-7474 and enter PIN 0151989. One can also join the call by dialling: sip:session_0151989@edial.internet2.edu on a SIP-enabled voice communications client. If the SIP client cannot dial URLs, you can have the conference system call you if you have the sip URL for your phone. Go to https://edial.internet2.edu/call/0151989 and type in the URL to your phone, and follow the directions. _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team From tools-team-bounces@ietf.org Wed Jun 14 13:39:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZL9-0005eX-2V; Wed, 14 Jun 2006 13:39:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZL7-0005eQ-Bj for tools-team@ietf.org; Wed, 14 Jun 2006 13:39:37 -0400 Received: from av9-2-sn2.hy.skanova.net ([81.228.8.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqZL5-00012s-Ta for tools-team@ietf.org; Wed, 14 Jun 2006 13:39:37 -0400 Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id 1A151382E4; Wed, 14 Jun 2006 19:39:35 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 0A34338043; Wed, 14 Jun 2006 19:39:35 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id ECE5937E46; Wed, 14 Jun 2006 19:39:34 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FqZL3-0003Z8-SK; Wed, 14 Jun 2006 19:39:34 +0200 Message-ID: <449049D5.9030204@levkowetz.com> Date: Wed, 14 Jun 2006 19:39:33 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Tools-team] Agenda for the 14 June 2006 Teleconference References: <44902CF5.4030606@levkowetz.com> <17552.16412.516987.746408@fireball.kivinen.iki.fi> In-Reply-To: <17552.16412.516987.746408@fireball.kivinen.iki.fi> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Tools-team X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0143312258==" Errors-To: tools-team-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0143312258== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig60C17D0E3496C4D902647651" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig60C17D0E3496C4D902647651 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tero, on 2006-06-14 18:58 Tero Kivinen said the following: > Henrik Levkowetz writes: >> 2. Status review >>=20 >> * Dashboard >> - Henrik >=20 > Some comments about loginmgr. >=20 > 1) That login manager really needs to require TLS protection, i.e > mandate that both the forms and the posts are always using TLS. Yes. But to do that, I need a proper cert for tools.ietf.org, which I don't have. I've been planning to talk with Ray about it for some time, but no time... I assume that this has to go through some entity that can verify that we have a right to get a cert for tools.ietf.org. I also wonder if we need separate certs for tools.ietf.org, www1.tools.ietf.org, www2.tools.ietf.org and www3.tools.i= etf.org... > 2) The URL for changing password should only work exactly once, not > for 24 hours. The problem with 24 hours is that if someone manages > to get the URL later from my mailbox or some other place he can > change my password after I changed it. If it works exactly once, > either I will get error that password has already been changed > using the URL (i.e. I know there was attacker who stole my URL) or > the attacker cannot change my password after I have successfully > changed it. Perhaps storing the used auth sha1sum to some directory > and checking that it cannot be there before continuing. I agree, and this is already on my todo list, but I wanted to get the base functionality out there first. This can be accomplished without changing what I have now, only putting in an additional check in the script which verifies the hash. Something else which you haven't mentioned but is also on my todo list is rate limiting on requesting the mail with a new password URL, so people can't anonymously annoy others with a stream of mails with new password URLs. Thanks for the feedback :-) Henrik --------------enig60C17D0E3496C4D902647651 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEkEnVeVhrtTJkXCMRAmocAJ0TBVnEgAFu0oPFvPv+dLFluc5eWACgkz49 iuvZtgoJMHnsGsJ3Z2aOof4= =qV8d -----END PGP SIGNATURE----- --------------enig60C17D0E3496C4D902647651-- --===============0143312258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team --===============0143312258==-- From tools-team-bounces@ietf.org Thu Jun 15 05:09:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqnqs-0007zJ-Ds; Thu, 15 Jun 2006 05:09:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqnqr-0007z7-Hh for tools-team@ietf.org; Thu, 15 Jun 2006 05:09:21 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqnqp-0003q2-VP for tools-team@ietf.org; Thu, 15 Jun 2006 05:09:21 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k5F99HXx012079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jun 2006 12:09:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k5F99Hff029210; Thu, 15 Jun 2006 12:09:17 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17553.9149.494061.90468@fireball.kivinen.iki.fi> Date: Thu, 15 Jun 2006 12:09:17 +0300 From: Tero Kivinen To: Henrik Levkowetz Subject: Re: [Tools-team] Agenda for the 14 June 2006 Teleconference In-Reply-To: <449049D5.9030204@levkowetz.com> References: <44902CF5.4030606@levkowetz.com> <17552.16412.516987.746408@fireball.kivinen.iki.fi> <449049D5.9030204@levkowetz.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 13 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Tools-team X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tools-team-bounces@ietf.org Henrik Levkowetz writes: > > 1) That login manager really needs to require TLS protection, i.e > > mandate that both the forms and the posts are always using TLS. > > Yes. But to do that, I need a proper cert for tools.ietf.org, which > I don't have. I've been planning to talk with Ray about it for some > time, but no time... I assume that this has to go through some > entity that can verify that we have a right to get a cert for > tools.ietf.org. I also wonder if we need separate certs for > tools.ietf.org, www1.tools.ietf.org, www2.tools.ietf.org and > www3.tools.ietf.org... As datatracker.ietf.org already has certificate, I assume someone knows how to get one... And yes, you probably need separate certificates for each host if you want to run separate tasks on each of them. If they are all identical i.e. referred always as tools.ietf.org, then one certificate would be enough, but I guess there will be some services that will be only on the www1.tools.ietf.org and not on the others. > > > 2) The URL for changing password should only work exactly once, not > > for 24 hours. The problem with 24 hours is that if someone manages > > to get the URL later from my mailbox or some other place he can > > change my password after I changed it. If it works exactly once, > > either I will get error that password has already been changed > > using the URL (i.e. I know there was attacker who stole my URL) or > > the attacker cannot change my password after I have successfully > > changed it. Perhaps storing the used auth sha1sum to some directory > > and checking that it cannot be there before continuing. > > I agree, and this is already on my todo list, but I wanted to get the > base functionality out there first. This can be accomplished without > changing what I have now, only putting in an additional check in the > script which verifies the hash. I that can be quite easily added, by simply adding check after the auth data checking saying (using /bin/sh syntax as example) if [ -f "$authfilesdir/$auth" ] then echo "Auth key already used" exit 1 else # Auth key ok, mark it as used touch "$authfilesdir/$auth" fi And then put cronscript that will remove all files from the $authfilesdir/$auth that are older than one day. > Something else which you haven't mentioned but is also on my todo list > is rate limiting on requesting the mail with a new password URL, so > people can't anonymously annoy others with a stream of mails with > new password URLs. If someone really starts sending thousands of those emails to some user then he must use quite a lot of his own bandwidth to send those requests, and after a while the tools.ietf.org machine will get slow as sending out those emails takes cpu resources... What you do want to do is to add the information who sent the request i.e add things like: ---------------------------------------------------------------------- This request was made from 62.61.72.13:57673 Browser Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.7.12) Gecko/20051028 ---------------------------------------------------------------------- to the end of the email that is sent to the user when password is requested. That way user will at least know IP-address who is sending those requests, and can himself continue pursuing the attacker instead of asking you to check www-server logs... I.e. add echo "This request was made $ENV{'REMOTE_ADDR'}:$ENV{'REMOTE_PORT'}" echo "Browser $ENV{'HTTP_USER_AGENT'}" to the end of email. -- kivinen@safenet-inc.com _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team From tools-team-bounces@ietf.org Thu Jun 15 05:28:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqo9m-0001Sj-QW; Thu, 15 Jun 2006 05:28:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqo9l-0001Sd-Nt for tools-team@ietf.org; Thu, 15 Jun 2006 05:28:53 -0400 Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqo9k-0004YO-6H for tools-team@ietf.org; Thu, 15 Jun 2006 05:28:53 -0400 Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 587EF37E82; Thu, 15 Jun 2006 11:28:51 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id 4656737E43; Thu, 15 Jun 2006 11:28:51 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id EF67837E47; Thu, 15 Jun 2006 11:28:50 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1Fqo9h-00046p-1i; Thu, 15 Jun 2006 11:28:50 +0200 Message-ID: <44912851.1090501@levkowetz.com> Date: Thu, 15 Jun 2006 11:28:49 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Tools-team] Agenda for the 14 June 2006 Teleconference References: <44902CF5.4030606@levkowetz.com> <17552.16412.516987.746408@fireball.kivinen.iki.fi> <449049D5.9030204@levkowetz.com> <17553.9149.494061.90468@fireball.kivinen.iki.fi> In-Reply-To: <17553.9149.494061.90468@fireball.kivinen.iki.fi> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Tools-team X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0897485159==" Errors-To: tools-team-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0897485159== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2C7797045D16A1216DCF0D49" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C7797045D16A1216DCF0D49 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tero, on 2006-06-15 11:09 Tero Kivinen said the following: > Henrik Levkowetz writes: >> > 1) That login manager really needs to require TLS protection, i.e >> > mandate that both the forms and the posts are always using TLS. >>=20 >> Yes. But to do that, I need a proper cert for tools.ietf.org, which >> I don't have. I've been planning to talk with Ray about it for some >> time, but no time... I assume that this has to go through some >> entity that can verify that we have a right to get a cert for >> tools.ietf.org. I also wonder if we need separate certs for >> tools.ietf.org, www1.tools.ietf.org, www2.tools.ietf.org and >> www3.tools.ietf.org... >=20 > As datatracker.ietf.org already has certificate, I assume someone > knows how to get one... Oh, I agree. That won't be the problem, I hope. > And yes, you probably need separate > certificates for each host if you want to run separate tasks on each > of them. If they are all identical i.e. referred always as > tools.ietf.org, then one certificate would be enough, but I guess > there will be some services that will be only on the > www1.tools.ietf.org and not on the others.=20 Right. >>=20 >> > 2) The URL for changing password should only work exactly once, not >> > for 24 hours. The problem with 24 hours is that if someone manage= s >> > to get the URL later from my mailbox or some other place he can >> > change my password after I changed it. If it works exactly once, >> > either I will get error that password has already been changed >> > using the URL (i.e. I know there was attacker who stole my URL) o= r >> > the attacker cannot change my password after I have successfully >> > changed it. Perhaps storing the used auth sha1sum to some directo= ry >> > and checking that it cannot be there before continuing. >>=20 >> I agree, and this is already on my todo list, but I wanted to get the >> base functionality out there first. This can be accomplished without >> changing what I have now, only putting in an additional check in the >> script which verifies the hash. >=20 > I that can be quite easily added, by simply adding check after the > auth data checking saying (using /bin/sh syntax as example) >=20 > if [ -f "$authfilesdir/$auth" ] > then > echo "Auth key already used" > exit 1 > else > # Auth key ok, mark it as used > touch "$authfilesdir/$auth" > fi Sure, straightforward. >=20 > And then put cronscript that will remove all files from the > $authfilesdir/$auth that are older than one day.=20 Certainly. >> Something else which you haven't mentioned but is also on my todo list= >> is rate limiting on requesting the mail with a new password URL, so >> people can't anonymously annoy others with a stream of mails with >> new password URLs. >=20 > If someone really starts sending thousands of those emails to some > user then he must use quite a lot of his own bandwidth to send those > requests, and after a while the tools.ietf.org machine will get > slow as sending out those emails takes cpu resources... The annoyance value of 50 emails from a source you don't want to block is considerable - it's not so much a bandwidth issue as an annoyance issue, and I'd rather prevent that. Your proposed fix below makes it possible to pursue the miscreant, but doesn't prevent the annoyance... > What you do want to do is to add the information who sent the request > i.e add things like: >=20 > ---------------------------------------------------------------------- > This request was made from 62.61.72.13:57673 > Browser Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.7.12) Gecko/20051= 028 > ---------------------------------------------------------------------- >=20 > to the end of the email that is sent to the user when password is > requested. That way user will at least know IP-address who is sending > those requests, and can himself continue pursuing the attacker instead > of asking you to check www-server logs... >=20 > I.e. add >=20 > echo "This request was made $ENV{'REMOTE_ADDR'}:$ENV{'REMOTE_PORT'}" > echo "Browser $ENV{'HTTP_USER_AGENT'}" >=20 > to the end of email. Yes, I may add something like this, it may be useful even if I add rate limiting. Regards, Henrik --------------enig2C7797045D16A1216DCF0D49 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEkShReVhrtTJkXCMRArThAJ4t7kTs2p9XsdL9cM0TkyLkhQ5hvwCaA4yo 1zQzxOJx8/gdrHYLPBsjuLU= =vPKI -----END PGP SIGNATURE----- --------------enig2C7797045D16A1216DCF0D49-- --===============0897485159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team --===============0897485159==-- From tools-team-bounces@ietf.org Wed Jun 28 09:38:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvaFS-0001pv-Rr; Wed, 28 Jun 2006 09:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvaFS-0001pl-9x for tools-team@ietf.org; Wed, 28 Jun 2006 09:38:30 -0400 Received: from av11-2-sn2.hy.skanova.net ([81.228.8.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvaFP-0008O7-UE for tools-team@ietf.org; Wed, 28 Jun 2006 09:38:30 -0400 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id 04AA338523; Wed, 28 Jun 2006 15:38:27 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id EC7A137F25 for ; Wed, 28 Jun 2006 15:38:26 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id DA80F37E4B for ; Wed, 28 Jun 2006 15:38:26 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FvaFL-0003zV-7t; Wed, 28 Jun 2006 15:38:26 +0200 Message-ID: <44A2864E.1020300@levkowetz.com> Date: Wed, 28 Jun 2006 15:38:22 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Tools-team Subject: [Tools-team] Agenda for the 28 June 2006 Teleconference X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tools-team-bounces@ietf.org Hi, Here is the proposed agenda for today's call. ------------------------------------------------------------------------ 1. Agenda bashing and comments on previous minutes 2. Status review * Dashboard - Henrik * Issue trackers, Wiki - Henrik * Review team support tool - Tero * Draft info draft - Alex * Meta-information schema - Stas 4. Google Summer of Code info 5. Any other business 6. Next meeting: Teleconference Wednesday August 23rd, 16:00 GMT (same local time as today). Note the summer hiatus. ------------------------------------------------------------------------ Connection details: To join the call, dial +1-734-615-7474 and enter PIN 0151989. One can also join the call by dialling: sip:session_0151989@edial.internet2.edu on a SIP-enabled voice communications client. If the SIP client cannot dial URLs, you can have the conference system call you if you have the sip URL for your phone. Go to https://edial.internet2.edu/call/0151989 and type in the URL to your phone, and follow the directions. _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team From tools-team-bounces@ietf.org Wed Jun 28 12:34:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvczi-00019d-GS; Wed, 28 Jun 2006 12:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvczC-0000Nz-8w for tools-team@ietf.org; Wed, 28 Jun 2006 12:33:54 -0400 Received: from av7-1-sn3.vrr.skanova.net ([81.228.9.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvckq-0008Eq-C7 for tools-team@ietf.org; Wed, 28 Jun 2006 12:19:06 -0400 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 912A937F1F; Wed, 28 Jun 2006 17:52:35 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 8325D37E75 for ; Wed, 28 Jun 2006 17:52:35 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 807A937E4A for ; Wed, 28 Jun 2006 18:19:03 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1Fvckm-0000fq-TH; Wed, 28 Jun 2006 18:19:02 +0200 Message-ID: <44A2ABF4.3080608@levkowetz.com> Date: Wed, 28 Jun 2006 18:19:00 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Tools-team X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Tools-team] Minutes from the 28 June 2006 Teleconference X-BeenThere: tools-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "The purpose of the TOOLS team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tools-team-bounces@ietf.org Hi, Here are the minutes from today's call. ------------------------------------------------------------------------ 0. Present: Alex, Tero, Henrik 1. Agenda bashing and comments on previous minutes None 2. Status review * Dashboard - Henrik Progress on the prerequisites of assembling normalized data for the dashboard, from various input sources. Graphing and web pages has yet to be done. * Issue trackers, Wiki - Henrik Close to ready to release - not sure whether it's best to do it before or after the meeting. Alex suggests before would be good. Most comments on the login manager fixed. * Review team support tool - Tero Has been on vacation :-) * Draft info draft - Alex Waiting for comments on the draft. Tero will read it when back from vacation. * Meta-information schema - Stas No info. 4. Google Summer of Code info The project is progressing well, with a beta version close. The tools team will be notified when beta testing is available. 5. Any other business None 6. Next meeting: Teleconference Wednesday August 23rd, 16:00 GMT (same local time as today). Note the summer hiatus. ------------------------------------------------------------------------ Connection details: To join the call, dial +1-734-615-7474 and enter PIN 0151989. One can also join the call by dialling: sip:session_0151989@edial.internet2.edu on a SIP-enabled voice communications client. If the SIP client cannot dial URLs, you can have the conference system call you if you have the sip URL for your phone. Go to https://edial.internet2.edu/call/0151989 and type in the URL to your phone, and follow the directions. _______________________________________________ Tools-team mailing list Tools-team@ietf.org https://www1.ietf.org/mailman/listinfo/tools-team