返回首页

RFC 4714 - Requirements for IETF Technical Publication Servi(2)

时间:2006-11-02 来源: 作者: 点击:
inputASCIItextfilesandpublishdocumentsasASCIItextfiles andPDFfiles. oReq-DOCCONVERT-2-Thetechnicalpublishershouldaccept supplementalfilesthatmaycontaininformationsuchascode, formaldescriptions(e.g.,X
  
      input ASCII text files and publish documents as ASCII text files
      and PDF files.

   o  Req-DOCCONVERT-2 - The technical publisher should accept
      supplemental files that may contain information such as code,
      formal descriptions (e.g., XML, ASN.1) graphics, data files, etc.
      Supplemental files may also include enhanced versions of the
      document containing graphics or sections not presentable in text
      format.  Any supplemental files, barring any changes to the IETF
      process rules, will be associated with the published IETF
      documents, but may not be editable by the publisher.

3.10.  Language Translation

   Task Description: Some standards organizations require publication of
   documents in multiple languages.  This translation is the
   responsibility of the technical publisher.

   Discussion: IETF specifications are published only in English.

   Derived Requirements: none

3.11.  Publication Status Tracking

   Task Description: The technical publisher should have the ability to
   provide status information on the status of a document.  This may
   involve developing a process model or a checklist and providing

   information on a document’s state, outstanding issues, and
   responsibility tokens.  Depending on the need for transparency, this
   information may need to be available online and continuously updated.

   Discussion: The RFC Editor currently provides status information via
   the RFC Editor queue.  Each document is attributed a status (e.g.,
   AUTH48, RFC-EDITOR, IANA, ISR).  Items may stay in the queue for a
   long time without changing status.  This status tracking information
   is not integrated with the IESG tracking tools.  Within the IETF, the
   Process and Tools (PROTO) team is considering requirements for
   marking the token-holder accurately during long waiting periods, and
   others are looking into improved notification tools.  Requirements on
   the IETF technical publisher for improved status integration and
   visibility could be met by collaborations with these efforts, by
   providing public access to email logs regarding publications, or by
   some other proposal.

   Derived Requirements:

   o  Req-STATUSTRK-1 - The IETF technical publisher should make state
      information publicly available for each document in the
      publication process.  It is desirable that this information be
      available through a documented interface to facilitate tools
      development.

   o  Req-STATUSTRK-2 - The IETF technical publisher should integrate
      its state information with the IETF tools to provide end-to-end
      status tracking of documents.  For the documents in the IETF
      standards process stream, it is expected that documents should be
      able to move seamlessly from the IETF standards tracking system
      into the technical publication tracking system.

   o  Req-STATUSTRK-3  - The IETF technical publisher should provide
      external visibility of not only the fact that a document is in an
      extended waiting period but also the token-holder and
      circumstances of the wait.

3.12.  Expedited Handling

   Task Description: In some cases (such as when the documents are
   needed by another standards body), it should be possible for the
   approving organization to request expedited publication of a
   document.  Ideally, this should not skip any of the publication
   steps, but allocates it higher priority in the work queue to ensure
   earlier publication than normal.  Expedited publication should be
   used sparingly since as with any priority scheme, overuse will negate
   its benefits.

   Discussion: The fast-tracking procedure is used to expedite
   publication of a document at the request of the IESG.  Fast-tracking
   is generally employed when an external organization has a looming
   publication deadline and a need to reference a document currently in
   the RFC Editor’s queue.  Having short publication times would likely
   reduce the need for fast-tracking.

   Since fast-tracking is disruptive to the work flow, it is recommended
   that expedited handling be phased out as soon as alternative ways of
   achieving timely publication are in place.

   Derived Requirements:

   o  Req-EXPEDITE-1 - The IETF technical publisher should expedite the
      processing of specific documents at the request of an appropriate
      authority.  For the IETF standards process stream, that authority
      is the IESG or the IAB.

3.13.  Exception Handling

   Task Description: It should be possible for various reasons for a
   document to be withdrawn from publication or the publication to be
   put on hold.  Reasons for this could be due to an appeals process,
   detection of a serious technical flaw, or determination that the
   document is unsuitable for publication.

   Discussion: For various reasons, a document can be withdrawn before
   publication.

   Derived Requirements:

   o  Req-EXCEPTIONS-1 - The IETF technical publisher should permit
      documents to be withdrawn from publication at the direction of an
      appropriate authority.  For the IETF standards process stream,
      that authority is the IESG.

   o  Req-EXCEPTIONS-2 - The IETF technical publisher should permit
      documents to be put on hold awaiting the outcome of an appeal at
      the direction of an appropriate authority.  For the IETF standards
      process stream, that authority is the IESG.

3.14.  Notification of Publication

   Task Description: The technical publisher should provide a mechanism
   for alerting the community at large of the availability of published
   documents.

   Discussion: The RFC Editor notifies the community of document
   publication on the rfc-dist and ietf-announce mailing lists.

   Derived Requirements:

   o  Req-PUBNOTIFY-1 - The IETF technical publisher should announce the
      availability of published documents.

3.15.  Post-publication Corrections (errata)

   Task Description: If corrections are identified after publication,
   the technical publisher should be able to publish errata that can be
   linked with the original document.

   Discussion: The RFC Editor maintains a list of errata.  Pointers to
   relevant errata are presented as output from the RFC Editor search
   engine.

   Derived Requirements:

   o  Req-ERRATA-1 - The IETF technical publisher should maintain errata
      for published documents.  The process for review, updating, and
      approval of errata for IETF documents will be defined by the IETF.

   o  Req-ERRATA-2 - The IETF technical publisher should provide
      information on relevant errata as part of the information
      associated with an RFC.

3.16.  Indexing: Maintenance of the Catalog

   Task Description: The technical publisher normally provides and
   maintains the master catalog of publications of that organization.
   As the publishers of the organization’s output, the technical
   publisher is expected to be the definitive source of publications and
   the maintainer of the database of published documents.  This also
   includes the cataloging and storage of meta-information associated
   with documents such as their history, status (e.g., updated,
   obsoleted), document categories (e.g., standard, draft standard,
   BCP).

   Discussion: The RFC Editor maintains the catalog.  The RFC Editor is
   also responsible for the permanent archival of specifications.
   Meta-information associated with an RFC should also be maintained.
   Since this is the definitive archive, sufficient security should be
   in place to prevent tampering with approved documents.

   Derived Requirements:

   o  Req-INDEX-1 - The IETF technical publisher should maintain the
      index of all IETF published documents.  It is desirable that the
      interface to the index be documented to facilitate tools
      development.

   o  Req-INDEX-2 - The IETF technical publisher should provide the
      permanent archive for published documents.

   o  Req-INDEX-3 - Meta-information associated with a published
      document must be stored and updated as its status changes.

   o  Req-INDEX-4 - The archive must be sufficiently secure to prevent
      the modification of published documents by external parties.

   o  Req-INDEX-5 - The IETF technical publisher should provide the
      permanent archive of any source documents associated with a
      published specification.

   o  Req-INDEX-6 - An appropriate authority can indicate to the
      publisher that it should change the status of a document (e.g., to
      Historical) and this should be reflected in the index.  For the
      IETF standards process stream, the indicating authority is the
      IESG.

3.17.  Access to Published Documents

   Task Description: The technical publisher should facilitate access to
   the documents published.  It is assumed that the technical publisher
   will provide online tools to search for and find information within
   the archive of published documents.  These access tools should
   facilitate understanding the state of the document (e.g.,
   identification of replacement or updated documents, linkage to
   pertinent errata).

   Discussion: Documents and status may be accessed via the RFC Editor’s
   web page.

   Derived Requirements:

   o  Req-PUBACCESS-1 - The IETF technical publisher should provide
      search tools for finding and retrieving published documents.

   o  Req-PUBACCESS-2 - The IETF technical publisher tool should return
      relevant meta-information associated with a published document
      (e.g., category of document, type of standard (if standards

      track), obsoleted by or updated by information, associated
      errata).

   o  Req-PUBACCESS-3  - The IETF technical publication search tools
      should be integrated with the IETF search tools.  For the IETF
      standards process stream, this refers to integration with the
      search tools used by the IETF standards process.

3.18.  Maintenance of a Vocabulary Document

   Task Description: Some standards organizations require the technical
   publisher to maintain a publicly available vocabulary document or
   database containing common terms and acronyms.  The goal is to
   provide consistency of terminology between documents.

   Discussion: The RFC Editor does not maintain a public document or
   database of terms or acronyms.

   Derived Requirements: none

3.19.  Providing Publication Statistics and Status Reports

   Task Description: The technical publisher may be required to
   periodically or continuously measure its performance.  In many
   standards organizations, performance targets are set in terms of
   timeliness, throughput, etc.

   Discussion: The IETF technical publisher currently provides monthly
   statistics on arrivals and completions of documents by category.  In
   addition, a status report is provided at each IETF meeting.  Other
   statistics can be used to judge the health of the editing process.
   Many of these statistics could be gathered using sampling techniques
   to avoid excessive load on the technical publisher.

   Derived Requirements:

   o  Req-STATS-1 - The IETF technical publisher should provide publicly
      available monthly statistics on average queue times and documents
      processed.  The presentation should provide a historical context
      to identify trends (see Goal-THROUGHPUT-1).  For the IETF
      standards process, this should include queue arrivals,
      completions, documents in the queue, and the number of documents
      in each state at the end of the month.

   o  Req-STATS-2 - The IETF technical publisher should provide periodic
      status reports at the IETF meetings to apprise the community of
      its work and performance.

   o  Req-STATS-3 - The IETF technical publisher should provide publicly
      available monthly statistics on the types of editorial corrections
      being found during reviews as well as the percentage of
      corrections that are rejected by the authors.

   o  Req-STATS-4 - The IETF technical publisher should provide publicly
      available monthly statistics on author-requested changes to
      documents under publication.  This statistic should also include
      changes required by other authorities outside of the technical
      publisher empowered to make changes.  For the IETF standards
      process, the designated authority would be the IESG or its
      designees.

3.20.  Process and Document Evolution

   Task Description: The guidelines and rules for an organization’s
   publication output will change over time.  New sections will be added
   to documents, styles and conventions will change, boilerplate will be
   changed, etc.  Similarly, the specific processes for publication of a
   specification will change.  The technical publisher is expected to be
   involved in these discussions and accommodate these changes as
   required.

   Discussion: Over time, the IETF consensus on what should be in a
   published document has changed.  Processes interfacing with the
   publisher have also changed.  Such changes are likely to continue in
   the future.  The RFC Editor has been involved in such discussions and
   provided guides, policies, faqs, etc. to document the current
   expectations on published documents.

   Derived Requirements:

   o  Req-PROCESSCHG-1 - The IETF technical publisher should participate
      in the discussions of changes to author guidelines and publication
      process changes.

   o  Req-PROCESSCHG-2 - The IETF technical publisher should participate
      in and support process experiments involving the technical
      publication process.

3.21.  Tutorial and Help Services

   Task Description: The technical publisher may be required to provide
   tutorials, mentoring, help desks, online tools, etc. to facilitate
   smooth interaction with the technical publisher and to increase the
   IETF community’s awareness of document guidelines, procedures, etc.
   In many organizations, the publisher maintains a style manual giving
   explicit guidance to authors on how to write a specification.

   Discussion: Guidelines are provided to the authors on how to write an
   RFC as well as occasional tutorial presentations.  The RFC Editor
   provides a help desk at IETF meetings.

   Derived Requirements:

   o  Req-PUBHELP-1 - The IETF technical publisher should provide and
      maintain documentation giving guidance to authors on the layout,
      structure, expectations, etc. required to develop documents
      suitable for publication.  For the IETF standards process stream,
      the technical publisher should follow IESG guidance in specifying
      documentation guidelines.

   o  Req-PUBHELP-2 - The IETF technical publisher should provide
      tutorials to the IETF community to educate authors on the
      processes and expectations of the IETF technical publisher.

   o  Req-PUBHELP-3 - The IETF technical publisher should provide a
      contact email address and correspond as required to progress the
      publication work.  The publisher should address queries from both
      inside and outside of the IETF community.

   o  Req-PUBHELP-4 - The IETF technical publisher should provide a help
      desk at IETF meetings.

3.22.  Liaison and Communication Support

   Task Description: It is very valuable for the technical publisher of
   an organization to have good information and communication about the
   work streams that will result in publication streams.  In order to
   ensure a wide communication channel for the work, the technical
   publisher holds a liaison position on the IESG, where there can be
   valuable give-and-take about matters concerning the IETF standards
   stream.

   Discussion: The RFC Editor currently maintains a liaison position
   with the IESG.  Although not specifically addressed in these
   requirements, the RFC Editor also maintains a liaison position toward
   the IAB.

   Derived Requirements:

   o  Req-LIAISON-1 - Through a liaison participant, the technical
      publisher should take part in meetings and activities as required
      in order to be aware of ongoing activities related to the work
      streams.  For the IETF standards stream the technical publisher
      should participate in IESG formal meetings, IESG face-to-face
      activities at IETF, and other activities such as retreats.

4.  Technical Publisher Performance Goals

   Technical publishers are typically measured not only on what they do
   but how well they perform the tasks.  The expectations in this
   section are treated as goals instead of requirements because:

   -  Achieving a given level of performance is not totally under the
      control of the technical publisher.  Publication is a process and
      the goals are of the process, not just the publisher.

   -  The actual performance objectives will be set contractually.  The
      values herein represent values that the IETF community feels are
      desirable and reasonable for work progress without consideration
      of financial or other factors.

   Goals are set forth in the following areas:

   1. Publication timeframes

   2. Publication throughput

4.1.  Publication Timeframes

   Goal Description: This is a measure of the time from entry into the
   RFC Editor queue until the documents are published.  The metrics are
   defined in (req-STATS-1).

   Discussion: Long publication times create both internal and external
   difficulties.  Internal difficulties include the migration of authors
   to other activities and the accumulation of tempting post-approval
   fixes to be added to the document.  External difficulties include the
   inability of other standards organizations to reference IETF
   publications for lack of an RFC number.

   Derived Goals:

   o  Goal-TIMEFRAMES-1 - The consensus of the IETF community is that an
      average publication time of under a month is desirable.  It is
      understood that in some cases there will be delays outside of the
      publisher’s control.  The actual performance targets and metrics
      are expected to be determined as part of the contract negotiation
      process.

   o  Goal-TIMEFRAMES-2 - The consensus of the IETF community is that
      the time required for a pre-approval review should be under 10
      days.  The actual performance targets and metrics are expected to
      be determined as part of the contract negotiation process.

4.2.  Publication Throughput

   Goal Description: The number of documents published during a given
   time period is a measure of publisher throughput.  Some publishers
   also provide the data in terms of pages produced.  The counts should
   be separated by categories of documents.  The metrics are defined in
   (req-STATS-1).

   Discussion: The RFC Editor currently provides monthly statistics on
   the arrival and completion of documents into the RFC queue.  This is
   sorted by category of document.  This provides a measure of the
   delays in the publication process.

   Derived Goals:

   o  Goal-THROUGHPUT-1 - Although minor variations are expected, there
      should be no long-term growth trend in the length of the
      publication queue.  The actual performance targets and metrics are
      expected to be determined as part of the contract negotiation
      process.

5.  IETF Implications of Technical Publication Requirements

   Requirements on the technical publication process have so far been
   stated in terms of requirements on the technical publisher.  However,
   it must be recognized that many of these requirements have
   implications for the processes and tools within the IETF itself.  It
   is anticipated that these processes will be documented in companion
   documents.

   The following is a list of potential issues that should be addressed
   within the IETF based on the requirements applied to the technical
   publisher:

   o  Pre- vs. Post-approval Editing: If emphasis switches from post-
      approval editing to pre-approval editing, then IETF processes must
      be adapted to make use of this service.  The processes for post-
      approval editing can also be streamlined.

   o  Post-approval Editorial Cleanup: The IETF must define under what
      conditions the publisher should be instructed to bypass or
      minimize post-approval editing.

   o  Approval of Post-approval, Pre-publication Technical Corrections:
      Since the technical publisher can only accept approved changes, it
      must be clear who is allowed to approve technical changes.  This
      process within the IETF needs to be decided and documented.

   o  Allocation of Permanent Stable Identifiers: The IETF needs to
      clearly identify the naming/numbering schemes and classes of
      documents to which those names and numbers apply.  Furthermore,
      the responsibility for allocation of those names/numbers needs to
      be identified.

   o  Expedited Handling: If publication timelines can be reduced
      sufficiently, then expedited handling may no longer be needed.

   o  Post-publication Corrections: Appropriate processes must be
      defined with the IETF to ensure that errata are appropriately
      vetted and authorized.

   o  Indexing: Appropriate processes must be defined within the IETF to
      decide and inform the technical publisher of status changes to
      published documents as the result of an appeal, legal action, or
      some other procedural action.

6.  IANA Considerations

   Any new requirements that result from this discussion need to be
   reviewed by IANA and the IETF to understand to what extent, if any,
   the work flow of the documents through IANA is affected.

   Interactions with IANA on population of parameter values is discussed
   in Section 3.6.

7.  Security Considerations

   There is a tussle between the sought-for improvements in readability
   and the specific language that has often been negotiated carefully
   for the security content of IETF documents.  As with other text,
   extreme caution is needed in modifying any text in the security
   considerations.  This issue is assumed to have been dealt with under
   Section 3.3.

   The processes for the publication of documents should prevent the
   introduction of unapproved changes (see Section 3.7).  Since the IETF
   publisher maintains the index of publications, sufficient security
   should be in place to prevent these published documents from being
   changed by external parties (see Section 3.16)

8.  Acknowledgements

   Bert Wijnen has provided input on the early copyedit experiment and
   made useful comments throughout the document.  Leslie Daigle has
   contributed strongly to this text.  Thanks to Steve Barclay, John
   Meredith, Yvette Ho Sang, and Sami Trabulsi for discussions of the
   publication practices of ATIS, ETSI, IEEE, and ITU.  Other
   acknowledgements to date: a discussion on the wg chairs mailing list,
   Henning Schulzrinne, and Henrik Levkowetz.

9.  Informative References

   [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
             the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
             May 2000.

Authors’ Addresses

   Allison Mankin
   Bethesda, MD
   USA

   Phone: +1 301 728 7199
   EMail: mankin@psg.com
   URI: http://www.psg.com/~mankin/

   Stephen Hayes
   Ericsson
   3634 Long Prairie Rd.
   Ste 108-125
   Flower Mound, TX 75022
   USA

   Phone: +1 469 360 8500
   EMail: stephen.hayes@ericsson.com

Full 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.

   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.

Intellectual Property

   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
------分隔线----------------------------
顶一下
(2)
100%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容