Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/internet-drafts/draft-sparks-genarea-manualpost-tracking-00.txt Дата изменения: Tue Oct 20 00:15:53 2015 Дата индексирования: Sun Apr 10 08:10:53 2016 Кодировка:

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

Abstract

This memo discusses requirements for improvements to the datatracker
related to tracking manual post requests.

Status of This Memo

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 Notice

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.






Sparks Expires April 21, 2016 [Page 1]

Internet-Draft manualpost October 2015


Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Description of desired functionality . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4

1. Introduction

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.




Sparks Expires April 21, 2016 [Page 2]

Internet-Draft manualpost October 2015


2. Description of desired functionality

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 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"



Sparks Expires April 21, 2016 [Page 3]

Internet-Draft manualpost October 2015


DocEvent include a link to the new version in the event's
description.

3. Security Considerations

This document discusses requirements for tools to improve tracking
manual post requests. There are no exceptional security
considerations introduced by these requirements.

4. IANA Considerations

This document has no actions for IANA.

Author's Address

Robert Sparks
Oracle
7460 Warren Parkway
Suite 300
Frisco, Texas 75034
USA

Email: rjsparks@nostrum.com




























Sparks Expires April 21, 2016 [Page 4]