[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4714

Network Working Group                                          A. Mankin
Internet-Draft                                            Shinkuro, Inc.
Expires: April 26, 2006                                         S. Hayes
                                                                Ericsson
                                                        October 23, 2005


          Requirements for IETF Technical Publication Service
                        draft-mankin-pub-req-01

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 April 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The work of the IETF is to discuss, develop and disseminate technical
   specifiations to support the Internet's operation.  As the the IETF
   progresses, document and review of its requirements for the process
   and structure of its technical specification publication is
   increasingly important, in order to ensure continued support for the
   IETF's work.




Mankin & Hayes           Expires April 26, 2006                 [Page 1]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Stages in the Technical Specification Publication
           Lifetime . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Requirements Discussion  . . . . . . . . . . . . . . . . . . .  6
   4.  Requirements for IETF Technical Specifications Publication
       Process  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Beginning-to-end Status Tracking . . . . . . . . . . . . .  7
     4.2.  Post-approval timeframes . . . . . . . . . . . . . . . . .  7
     4.3.  Fast Tracking  . . . . . . . . . . . . . . . . . . . . . .  8
     4.4.  Non-Author Editing . . . . . . . . . . . . . . . . . . . .  9
     4.5.  Post-Approval, Pre-Publication Changes . . . . . . . . . . 11
     4.6.  Post-Publication Changes: Maintaining and Updating
           Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.7.  Mechanisms for Changes to Tech Spec Style  . . . . . . . . 12
     4.8.  Indexing: Publisher Maintenance of the Catalog . . . . . . 12
     4.9.  What is the Permanent Stable Identifier? . . . . . . . . . 12
   5.  Two Experiments  . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  Early Copy Editing of WG Documents by the RFC Editor . . . 13
     5.2.  Stable Permanent Identifier at Approval  . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20























Mankin & Hayes           Expires April 26, 2006                 [Page 2]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


1.  Introduction

   The work of the IETF is to discuss, develop and disseminate technical
   specifications to support the Internet's operation.  An important
   output of the IETF, then, is published technical specifications.  As
   the IETF progresses, documentation and review of its requirements for
   the process and structure of technical specification publication is
   increasingly important, in order to ensure continued support for the
   IETF's work.

   The term "technical specification" is used here purposefully to refer
   to the technical output of the IETF.  This document does not engage
   in the debate about whether it is expressed as RFCs or ISDs, what
   "is" an RFCs, how to classify, etc.  All of that is out of scope.

   The intention of this document is to clarify the IETF's consensus on
   its requirements for its technical publication service.  Discussing
   these requirements in relation to the existing service carried out by
   the RFC Editor is not a goal of this document.  However, short and
   mid-term experiments with newly understood requirements can be
   performed in collaborations by the IETF and RFC Editor.  This is the
   subject of Section 5.





























Mankin & Hayes           Expires April 26, 2006                 [Page 3]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


2.  Scope

   The scope of this document is very specifically on the requirements
   of the publication process for technical specifications, leaving
   aside many of the other important topics related to the contribution
   to and creation of Internet-Drafts.

   Examples of topics that are meaningful, but are consciously not
   addressed here, include:

   o  Specifics about non-technical document contents about which the
      the IETF and the publisher both have preference (such as contents
      of acknowledgement sections, reference classifications)

   o  Structure of the non-technical document contents (such as their
      order or formats), again about which the IETF and the publisher
      both have preferences.

   o  The large meta-topic of document formats -- it is imperative to
      get a firm agreement on the entire technical specification
      publication process before zeroing in on formats for any part of
      it.  Nevertheless, it is important that the requirements laid out
      here do not place undue restrictions on future document format
      possibilities.

   Though these three points are out of scope here, the following
   proposed requirement encompasses addressing them in future:

      Req-1 The IETF should approve, or if needed, create and approve, a
      document describing the features of its technical publications,
      both the contents and policies on non-technical features, and
      structural matters such as the acceptable orderings of sections.

   The IETF should eventually approve a proposal for meeting its
   technical document requirements in terms of document format and
   processing, through the lifecycle shown in Figure 1 below.  This
   topic is deferred from discussion at this time in part because this
   topic probably must span the whole lifecycle rather concerning only
   technical publication requirements.

2.1.  Stages in the Technical Specification Publication Lifetime

   Figure 1 below provides a useful summary of where technical
   publication falls in the current lifetime of a document in the IETF.
   This figure shows a working group document and the review includes an
   IETF Last Call (LC).  The lifetime is very similar for AD-sponsored
   IETF documents, such as documents which update IETF protocols where
   there is no longer a working group, or documents on interdisciplinary



Mankin & Hayes           Expires April 26, 2006                 [Page 4]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


   topics.



           |  Author      | WGLC       | IESG,      |    |  Tech
   Actors  |  or          | AD         | Shepherd,  |  A |  Publisher,
           |  Editor      | IETF LC    | Editor,    |  P |  input from
           |              | IANA       | WG         |  P |  authors, et al
           |              | IESG       |            |  R |
   Actions |  Creation    |            | Resolution |  O |  non-author
           |  and         | Formal     | of all     |  V |  editing,
           |  Editing     | Reviewing  | reviews    |  A |  other
           |              |            |            |  L |  publication

           |_________________| |______________________| |_________________|

               In WG               Out of WG -            Post-Approval
                                   Pre-Approval

   Figure 1: Stages of a Working Group Document































Mankin & Hayes           Expires April 26, 2006                 [Page 5]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


3.  Requirements Discussion

   The rest of this document discusses a series of requirements or
   postulated requirements for the IETF on the post-approval technical
   publication of its documents.  For two of them, in Section 5, the
   stance of the document is to describe an experiment for a directed
   change from the 2005 situation, but otherwise, as stated, the
   requirements are presented in the abstract.

   o  Beginning-to-end status tracking - more view into publication

   o  Post-approval timeframes

   o  Fast tracking

   o  Non-author editing (publisher editing)

   o  Post-approval, pre-publication changes (by the IETF)

   o  Mechanisms for changes to technical publication style

   o  Errata

   o  Beyond errata

   o  Indexing: publisher maintenance of the catalog

   o  What is the permanent stable identifier?

   The IETF will determine in reviewing these what services best support
   its technical publication needs, and the result should be the set of
   requirements in this document expressed as firm requirements based on
   consensus.  Then when the IAB, the IETF Administrator Director (IAD)
   and the IETF Administrative Oversight Committee (IAOC) RFC 4071 [2].
   administer the Technical Publisher relationship for the IETF, they
   have a clear picture of the IETF's expressed requirements.  In
   addition, the IETF can use these requirements, if expressed clearly
   enough, as a baseline when new or extended services are implemented.













Mankin & Hayes           Expires April 26, 2006                 [Page 6]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


4.  Requirements for IETF Technical Specifications Publication Process

   This section lists the set of requirements for IETF technical
   specifications publication.  In each case, the current status is
   described (in terms of the extent to which the requirement is met
   and/or the means in which it is handled).  Illustrations are
   provided.

4.1.  Beginning-to-end Status Tracking

   In order to function as a full publication process, enabling all
   participants to fully contribute to, review, revise and reference
   specifications, it is imperative that all members of the IETF
   community have current and accurate information about the status of a
   specification's publication.

      Req-2 IETF documents should be able to move seamlessly from the
      IETF tracking system into the technical publication tracking
      system.  (This discussion sets a requirement, but would not set
      forth how it would be accomplished).

      Req-3 The community should be obtain detailed status information
      on the publication process of IETF documents; for instance, both
      the IETF tracker and the technical publication tracker should
      provide external visibiity of not only the fact that a document is
      in an extended waiting period, but the token-holder or
      circumstance the wait.

   As with Req-2, Req-3 would not try to discuss how the fuller
   detailing would be provided.  On the IETF side, the PROTO team will
   consider requirements for marking the token-holder accurately during
   long waiting periods, and others are looking into improved
   notification tools The requirement set on the technical publisher
   could be met by collaborations with these efforts, or by providing
   public access to email logs regarding publications, or by some other
   proposal.

4.2.  Post-approval timeframes

   The IETF does not work in a vacuum.  Many organizations (SDOs and
   implementing entities) depend on the IETF's specifications.
   Therefore, the IETF needs to be able to provide permanent references
   for, and final text of, specifications within a fixed time from the
   IETF's approval.

   Currently, our agreement with our technical publisher (the RFC
   Editor) has called for final publication within 2 months of approval,
   with a stable permanent reference available a month before that.



Mankin & Hayes           Expires April 26, 2006                 [Page 7]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


   However, the RFC Editor has a policy of not issuing permanent
   references for any documents before final textual publication, and
   the baseline of publication within 2 months has proven elusive over
   recent years.  In special circumstances, a Fast Track expedite
   service may be requested, for document publication.  We discuss this
   requirement in Section 4.3.

   A consideration for the stable permanent reference is whether it
   should also be held out till the 2 month point.  RFC 2026 RFC 2026
   [1]. stipulates that a document approval may be appealed up till 2
   months after its approval.

   Note that the technical publisher meeting a strict post-approval
   timeframe for publication would depend on good discipline by everyone
   associated with the document.  It has implications for authors,
   editors, working group, and the IANA protocol parameter assignment
   staff: all of these must be committed to timely action for their
   followup on any final reviews, changes, and actions needed post-
   approval.  (Small delays add up shockingly if one is looking for a
   month or two month turn-around; the Area Director and the working
   group shepherd shepherding [3] must be proactive as coordinators and
   managers to keep a document on track for a short publication
   timeframe - see also Section 4.5, Post-Approval, Pre-Publication
   Changes, for more about this.

   The purpose of this section is not to discuss the current post-
   approval time-frame, though in the Section 5.2 below, we provide a
   suggestion for decoupling the provision of the stable permanent
   reference from the technical publishers editing queue present and
   future.  The purpose here is to understand is to propose two firm
   requirements, in the light of the above discussion, including the
   coordination issues:

      Req-4 Stable permanent reference one or two months after approval

      Req-5 Published document at a predictable time after approval

4.3.  Fast Tracking

   The technical publication service has a publication priority.  In the
   ideal case, the the IETF would produce documents less quickly than
   the publication service could publish them, but this cannot be
   guaranteed for all future circumstances, and is not the case at the
   present writing, so there is a (substantial) queue with categories of
   priority (IETF working group standards track have high priority
   currently, e.g.).

   Under special circumstances, with documentation, the IESG votes to



Mankin & Hayes           Expires April 26, 2006                 [Page 8]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


   ask IETF Secretariat to send a message requesting expedited
   publication for a newly approved document.  These circumstances are
   usually the requirement that the approved document have a stable
   permanent reference for another standards body's shortly to be
   published standard.  Our experience is that lacking the stable
   reference, other bodies often simply incorporate the text of the last
   snapshot internet-draft in an appendix to their document, which is
   highly undesirable.  But whether or not the pressure is as great as
   that, the expediting of the stable reference, called fast-tracking,
   is often a requirement.

   It seems likely that providing a stable permanent identifier within
   one or two months of approval (see Section 5.2) would eliminate most
   requests for technical publication Fast Tracking.

      Req-6 The IETF continues to requires Fast Track service requests,
      but the goal is for them to return to being rare, rather than
      frequent, e.g. needed because an eligible document approval has
      been accomplished with only a week or two to spare before its
      external deadline.

4.4.  Non-Author Editing

   In the post-approval period, the technical publisher performs an
   editing role.  This use of the word "edit" is very different from
   "editing" in the pre-approval period.  The WG's Editor manages
   language and consensus from the IETF working group, Last Call and
   review process.  The technical publisher's non-author editor, in the
   publication editing process, is interested not in any aspects of the
   IETF development, but only in improving readability, correcting
   spelling and grammar errors, and so on.  These are laudable goals in
   any piece of writing, and the IETF should always be attempting to
   give less onerous work to its technical publisher improving its texts
   and not "leaving that [known] writing for the publisher to fix".  But
   there are tradeoffs in the degree of non-author editing that is done,
   and the IETF needs to discuss the requirements it wants for this.

   How much copy editing is enough?  Here is a range of possibilities:

   o  corrections to errors only

   o  light rewriting

   o  significant editing of documents with less skillful WG editors,
      and minimal editing when the WG editors were skilled

   o  rewriting of all documents to the dictates of a style manual




Mankin & Hayes           Expires April 26, 2006                 [Page 9]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


   At times in the past year, stylistic editing has resulted in 40-100
   substantive changes in many documents.  A typical structure of Non-
   Author Editing is to make changes, and then ask all the authors
   separately to vet them, and go through rounds of author acceptance
   and re-vetting.  If the Post-approval timeframe is expected to be
   short, slowness in this process can be a serious problem.  There may
   be a tradeoff between the amount of consultation and improved
   communication that can be attained, and the amount of time that
   multiple documents will be waiting for work to progress.

   An issue for the IETF's assessment of non-author editing is that most
   individuals experience only a few publications a year at most,
   whereas WG Chair shepherds and Area Directors (and the technical
   publisher) view the throughput of larger number of publications.  Can
   the IETF support individual experiences of writing being improved for
   the best while also maintaining a high throughput of documents as
   desired by users of our specifications?

      Pre-Req-7 The IETF needs to construct a requirement for non-author
      editing balancing the quality effects with timeliness and other
      issues.  An example of balance is that the IETF could guide
      document shepherds to nominate one person in the author team to
      speak for all when a document is going to receive a heavier edit
      (and require the technical publisher to accept the document
      shepherd's leadership on this).

   A distinct issue from the convergence when there are many changes is
   the possibility of loss of technical meaning or loss of WG consensus
   wordings.  The more extensive forms of stylistic editing can change
   agreed on technical information or agreed on language (sometimes
   wording that has been settled on as part of a review).  At best, the
   loss in these cases is just time (and some tempers).  But since this
   activity occurs when the document has left the WG, there can be
   problems of determining whether the WG must become involved in the
   new language for a former WG consensus or technical matter, or if
   they must stay in the dark.  One is time-consuming and recycles the
   document, essentially, the other loses IETF transparency.

      Pre-Req-8 The IETF needs to construct a requirement for non-author
      editing regarding changes to technical and consensus wording.  Is
      the early copy editing experiment (see Section 5.1) a good
      solution, since the document receives its thorough editing for
      style before it leaves the working group, while the WG is still
      reviewing the document?







Mankin & Hayes           Expires April 26, 2006                [Page 10]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


4.5.  Post-Approval, Pre-Publication Changes

   Though occurring at the same time as the technical publisher's copy
   edits, the post-approval, pre-publicaton changes referred to in this
   section come from the IETF, and raise problems for us because they
   are often extensive and time-consuming.  The document becomes ready
   for publication, the copy edit comes to the authors and editors, and
   the primary author or perhaps several of them, present the publisher,
   with a long list of their own changes.  These fall into a number of
   categories, and it may be suggested that the IETF could agree that
   some of these are procedurally permitted (with appropriate steps) and
   some not:

   o  Changes the author or editor wants he or she thinks because
      document will read better

   o  Technical change WG has found and agreed on since approval

   o  Small update needed to match another spec approved since approval

   o  Serious technical bug found since approval

   The IETF has held that the author and editor are not the 'owners' of
   the document so that the first type is not viewed as an acceptable
   request (it would be acceptable during the time the editor is working
   on the document in the WG, but no longer during Post-Approval).

   The IETF should decide to accept the other types, but require them to
   be submitted only within a fixed time after approval, rather than
   having them submitted in the last few days before publication, when
   they contribute to delay.  The last type, the serious bug, clearly
   needs to be reportable up to the last moment.

      Req-9 Authors/IETF Editors must not initiate stylistic changes
      during the Post-Approval period.

      Req-10 Authors/IETF Editors/WGs may request small technical
      changes or small updates to a document (to match another approved
      specification) in the Post-Approval, period, but the IETF will
      require these to be presented to the document shepherd (and
      processed) within a set time period after approval has elapsed
      (following that period, issues with the document will be handled
      by other means).

4.6.  Post-Publication Changes: Maintaining and Updating Errata

   A technical publications service maintains errata for the
   publications.  If a bug or error is found after the document is



Mankin & Hayes           Expires April 26, 2006                [Page 11]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


   issued, rather than republishing a corrected copy, because of the
   stickiness of web copies, a specific error notice is placed on a web
   page.

   What does the IETF require for this service in terms of:

   o  Public awareness

   o  Review of the erratum (who reviews, transparency of review)

   o  Timeliness of posting

   o  Is this the right service?

   o  How does this interact with limiting the submission time for
      changes and updates to post-approval documents?

4.7.  Mechanisms for Changes to Tech Spec Style

   See Req-1

4.8.  Indexing: Publisher Maintenance of the Catalog

   To Come

4.9.  What is the Permanent Stable Identifier?

   The permanent stable identifiers of IETF documents are widely
   referenced (as the IETF technologies are widely used).  The current
   policy of the IETF is to publish our documents in a series whose
   identifiers the IETF does not manage.  Further we publish our
   standards and working group documents in this series, along with
   experimental drafts, documents receiving very light review such as
   those under the current URN policy, and so on.

      Proto-Req-11 The IETF should consider whether its own permanent
      stable identifier system would be of benefit, including being able
      to make clear the distinction in the identifier between IETF
      documents which have had more and less IETF review.












Mankin & Hayes           Expires April 26, 2006                [Page 12]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


5.  Two Experiments

   The following are presented as experiments for a current IETF/RFC
   Editor collaboration.  One is running currently.  The second could be
   proposed if this discussion results in interest; it is given a
   concrete form for that purpose.

5.1.  Early Copy Editing of WG Documents by the RFC Editor

   Time: September 20005 - November 2005

   Objectives: Improve document quality early on

   Experiment to perform as much of the editorial work as possible early
   in the process, e.g., before working group last call.

   This note describes a very limited initial experiment that should
   begin to sort out the issues.  We can then decide whether further
   experimentation is warranted.

   Expected impact:

   o  positive impact on WG Last Call, AD review, IETF Last Call and
      IESG review.  This is expected because of clearer/better text
      early on.

   o  less copy-editing, so faster process after IESG approval.  This
      hopefully reduces the time between IESG approval and RFC
      publication.

   o  Reduction of time spend in status AUTH48.  This is expected
      because there should be less changes (if any) between the approved
      text and the rfc-to-be-published.

   This seems to insert post-approval activity into the pre-approval
   period.  But in fact it makes what was a serial process a partly
   parallel one.  Part of the study is to determine if this
   parallelizing holds good, and there is not a long interlude on copy
   editing at the end of the publication period for these experiment
   documents.

5.2.  Stable Permanent Identifier at Approval

   A large fraction of IETF documents have either SDOs or implementor
   consumers who require a stable permanent identifier as soon as the
   document is approved.  This is a compliment to the value of the
   IETF's work.  Although simply providing the technical publications
   right away seems desirable, there are operations research arguments



Mankin & Hayes           Expires April 26, 2006                [Page 13]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


   to suggest that the IETF offer what the IETF can control, the output
   of the IETF's approval, not gated on a service we can only give
   requirements for.  Here is an outline for steps in an experiment for
   the IETF providing the stable permanent identifier at approval, and
   how this would modify the requirements for the technical publication:

   o  IESG approves document, which may include some text changes in the
      form of Notes to the Publisher

   o  IANA performs IANA actions for the document as usual and places
      usual i-d placeholder

   o  The two month timeout on appeals runs out (document approval is
      now final).  (As discussed above, this period could be shortened
      based on the view that approval rescissions are rare).

   o  The IESG assigns stable permanent identifer to the document and
      passes this to IANA and to the publisher.

   o  IANA can now update registry with the stable permanent identifier

   o  At this time the IETF's editor/author prepares a new draft with
      filename to be determined but which includes the stable permanent
      identifier

   o  The internal headers must be modified so that they include the
      stable permanent identifier and convey the approval status and
      non-expiration of the document, for instance:


   OLD:
   INTERNET-DRAFT
   September 5, 2005
   Expires: March 5, 2006


   NEW:
   RFC-TO-BE ####
   Approved September 30, 2005
   Expires at RFC Publication

   The new draft would not be as polished as the RFC publication, but it
   would incorporate the text changes and would be technically stable.
   Related to the section above on post-approval changes, if the
   timeframe for those is set in the same timeframe, this draft can be
   shepherded to include those and exclude all future, other than severe
   bugs that have been discovered.




Mankin & Hayes           Expires April 26, 2006                [Page 14]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


   The shepherds for the document should ensure that normative
   references for the document have stable permanent references already,
   for the citations.

   OPEN ISSUE: how to manage documents which are brought forward with
   normative references which will be significantly delayed beyond the
   window of permanent stable identifier issuance.  On first thought, it
   seems that such drafts need to be wait as before; the rationale for
   waiting for normative references is that the technology underlying
   the first approved work may change significantly by the time the
   later work comes to approval.  It is not always possible to secure
   completion of all work on which one's specification is dependent, but
   this is an important task for the document shepherds as the document
   progresses, to try to coordinate with the other work's progress.

   Other open issues are likely, besides execution questions such as the
   best string name for the post-approval draft.  However this
   experiment would pull together a number of the requirement threads.

































Mankin & Hayes           Expires April 26, 2006                [Page 15]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


6.  IANA Considerations

   Any 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 are affected.














































Mankin & Hayes           Expires April 26, 2006                [Page 16]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


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.  In general, it seems
   that clarifying the technical publication requirements seems likely
   to make sure that the IETF's secure protocols get out more
   effectively and with better result.











































Mankin & Hayes           Expires April 26, 2006                [Page 17]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


8.  Acknowledgements

   The early copy edit experiment writeup is by Bert Wijnen, and he made
   a number of useful comments on the rest.  Leslie Daigle has
   contributed strongly to this text throughout.  Other acknowledgements
   to date: a discussion on the wg chairs mailing list, Henning
   Schulzrinne, Henrik Levkowetz.

9.  Informative References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

   [2]  Austein, R. and B. Wijnen, "Structure of the IETF Administrative
        Support Activity (IASA)", BCP 101, RFC 4071, April 2005.

   [3]  Levkowetz, H. and D. Meyer, "The PROTO Process: Working Group
        Chair Document Shepherding",
        draft-ietf-proto-wgchair-doc-shepherding-05 (work in progress),
        March 2005.































Mankin & Hayes           Expires April 26, 2006                [Page 18]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


Authors' Addresses

   Allison Mankin
   Shinkuro, Inc.
   1025 Vermont Avenue
   Washington, DC  20005
   USA

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


   Stephen Hayes
   Ericsson


   Phone:
   Email: stephen.hayes@ericsson.com
   URI:































Mankin & Hayes           Expires April 26, 2006                [Page 19]

Internet-Draft       draft-mankin-techspec-pubreq-01        October 2005


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 (2005).  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.




Mankin & Hayes           Expires April 26, 2006                [Page 20]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/