| Network Working Group | R. Sparks |
| Internet-Draft | Oracle |
| Intended status: Informational | October 19, 2015 |
| Expires: April 21, 2016 |
Tracking Manual I-D Post Requests
draft-sparks-genarea-manualpost-tracking-00
This memo discusses requirements for improvements to the datatracker related to tracking manual post requests.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 21, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The transparency of the ID submission process needs to be improved, particularly for those submissions that are handled directly by the secretariat ("manual" and "forced" submissions).
When an author uses the datatracker submission tool, SubmissionEvents are captured, noting when the draft was submitted, when it was approved by previous authors (and by who), when it was approved by a WG chair if such approval was necessary, and when it was posted into the repository. Currently, the document's history shows only that a new version is available.
The submission tool presents an option to authors to request that the secretariat finish the submission process. The datatracker captures the candidate document and sends email to the secretariat. Often the request is made because the submission tool was unable to extract the correct meta-data from the document. In this case, the secretariat populates the meta-data, and forces the post. In other cases, there are issues identified by idnits that the secretariat helps diagnose, and the author is guided through fixing the issues and restarting the submission process with a repaired document. Again, SubmissionEvents are captured as the document goes through this process, but for drafts that are forced, the document history does not reflect these events.
The secretariat also receives requests to post a draft by direct email, bypassing the submission tool altogether. (Currently, the secretariat receives around 10 such requests each meeting cycle). The secretariat operates the submission tool on behalf of the author. The SubmissionEvents currently captured do not reflect that this was a manual submission request.
The secretariat currently relies on a combination of RT and personal email archives to keep track of the outstanding manual submission requests.
This project will address these issues through several improvements to the datatracker.
When a document is posted via the normal submission process, DocEvents reflecting the SubmissionEvents for the initial submission, the approval of previous authors, and the approval of a stream authority (such as WG chairs for a WG -00) will be added to the document. That is, where documents currently typically have a first history entry of "New version available: whatever-00", The first entries will be "New version submitted", "New version approved by previous author: (name)", "WG -00 approved by (name)", "New version available: whatever-00". The entries for subsequent versions are analogous.
When manual submission is requested via the submission tool, and the document is posted by the secretariat, DocEvents reflecting that the manual posting was requested, any approvals obtained, and that the document was forced will be added to the document. An example of the entries would be "Manual submission requested by (name)", "Meta-data set to <metadata%gt; by (name)", "WG -00 approved by (name)", "New version available: whatever -00".
When manual submission is requested by direct email, the secretariat will have the ability to tell the tracker that the request was received and upload the document from the email request, but not handle the request immediately. After this indication, the document will be in the same condition as a document requesting manual submission via the submission tool.
However the secretariat should not be forced to take that extra step if the request will be processed immediately. The submission tool should be modified to allow the secretariat to indicate they are submitting the document on behalf of an author at their request for manual submission. SubmissionEvents indicating that manual submission was requested will be created. Once the document is posted, DocEvents reflecting the history of the submission (as described for the above cases) will be created.
A page will be created (readable by anyone) that shows the set of outstanding manual submission requests. Each entry will either show, or provide navigation to a separate page that shows, the SubmissionEvent history for the outstanding submission. When logged in as the secretariat, there will be easy navigation from each entry to the page that allows processing the request.
Note that as of release 6.6.1, the manual submission process results in a DocEvent that says simple "New version available" without providing a link to the version that became available. This project will ensure that all paths that produce a "New version available" DocEvent include a link to the new version in the event's description.
This document discusses requirements for tools to improve tracking manual post requests. There are no exceptional security considerations introduced by these requirements.
This document has no actions for IANA.