2.2.3 New IETF Standards Track Discussion (newtrk)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional NEWTRK Web Page

Last Modified: 2004-11-01


Scott Bradner <sob@harvard.edu>

General Area Director(s):

Harald Alvestrand <harald@alvestrand.no>

General Area Advisor:

Harald Alvestrand <harald@alvestrand.no>

Mailing Lists:

General Discussion: newtrk@lists.uoregon.edu
To Subscribe: newtrk-request@lists.uoregon.edu
Archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

Description of Working Group:

The problem working group found that many IETF participants feel that
the current IETF hierarchy of Proposed, Draft and Full Standard maturity
levels for specifications is no longer being used in the way that was
envisioned when the stratification was originally proposed. In practice,
the IETF currently has a one-step standards process. The goal of this
working group is to agree on a revised IETF Standards Track, to replace
the standards track described in RFC 2026. The working group will also
decide on a process path forward.

The disparity between the documented IETF standards process and what is
used in practice can cause confusion on the part of those people or
organizations that use IETF technologies. It has also led to a general
disregard of the cautions in RFC 2026 on the appropriate deployment of
IETF technologies described in Internet Drafts or Proposed Standard

The NewTrk working group is a follow on to the newtrk BOF held during
the 58th IETF Meeting in Minneapolis. That BOF was held as a result of
the work of the problem working group.

The sense of the room at the end of the newtrk BOF was that:
1/ some change was needed to the IETF Standards Track
2/ a revised standards track should have more than one stage
3/ there should be some form of "working group snapshot," this might
or might not be a formal stage on the standards track and might or might
not be an archival publication
4/ at least one stage should require multiple interoperable
implementations of the technology to ensure document clarity
5/ any revised standards track should include some type of "IPR hook"
to keep the IETF and IESG out of the business of determining what IPR
claims are legitimate and what licensing terms are fair.

The goal of this working group is to agree on a revised IETF Standards
Track, taking into consideration the above points, to replace the
standards track described in RFC 2026. The working group will also
decide on a process for making forward progress. Some of the possible
paths being producing a revised version of RFC 2026 (and maybe other
RFCs), producing a standalone document or documents that update parts of
the existing RFCs or a mixture of the two. There may be other

The working group should also take into account other issues raised by
the problem working group and during the newtrk BOF as needed.

The deliberations of the working group will cover at least the following
a/ the standards track itself (number of stages, movement between
maturity levels, working group snapshots, maintenance, IPR issues)
b/ access to the standards track for individual submissions
c/ non-standards track document categories including BCP,
Informational, Experimental, and Historic and their relationship to the
standards track
d/ usability of the standards track (bug fixes, version numbers,
grouping multiple specifications, and maybe deprecation)
e/ development of a primary marker to distinguish documents
originating from the IETF from those not originating from the IETF

Discussions in the working group since the NewTrk BOF have added two
possible additional topics to the working group's agenda.

As part of a revised standards track process, the group will also
explore the creation of a new series of short IESG-approved IETF
documents to describe and define IETF technology standards. These
documents should be able to be used to define the IETF understanding of
what constituted a specific IETF standard at particular points in time.
The working group will also consider the usefulness of implementation
and or interoperability registers in conjunction with such a document

The working group will also discuss the usefulness of new "cleanup"
procedures to reclassify existing standards track RFCs based on breadth
of adoption (or lack of it) or the risk to the Internet of the
technology described in the RFC.

The NewTrk working group will coordinate its work with other reform
activities currently underway in the IETF.

Goals and Milestones:

Done  Publish ID describing new document series to describe and define individual IETF technology standards
Done  Publish ID describing a new RFC cleanup process
Oct 04  Determine if there is consensus to proceed with defining a new RFC cleanup process
Dec 04  If the consensus was to create a new RFC cleanup process then submit an ID describing the process to IESG for publication as a BCP RFC
Dec 04  Determine if there is consensus to proceed with a new document series to describe and define individual IETF technology standards
Dec 04  Publish initial Internet-Draft(s) describing a revised IETF standards track
Apr 05  If the consensus was to create a new document series to describe and define individual IETF technology standards, submit ID describing the series to IESG for publication as a BCP RFC
Apr 05  Submit final Internet-Draft(s) describing a revised IETF standards track to IESG for publication as a BCP
Apr 05  Submit final Internet-Draft(s) describing a revised IETF standards track to IESG for publication as a BCP


  • draft-ietf-newtrk-proposals-00.txt
  • draft-ietf-newtrk-repurposing-isd-00.txt
  • draft-ietf-newtrk-cruft-00.txt
  • draft-ietf-newtrk-sample-isd-stdproc-00.txt
  • draft-ietf-newtrk-sample-isd-00.txt

    No Request For Comments

    Current Meeting Report

    New IETF Standards Track Discussion (newtrk) WG

    Wednesday, November 10 at 1300-1500

    CHAIR: Scott Bradner <sob@harvard.edu>

    minutes based on notes by Spencer Dawkins


    I - Welcome & Agenda Bash - chair 5

    II - Cruft
    should we decruft - chair 10
    decrufting details - Lear/Alvestrand 25
    III - Labeling Standards - Klensin/Loughney 45
    IV - Naming RFCs - Rosenberg/Mankin 20

    I - Welcome & Agenda Bash
    There were no changes to the prepublished agenda.

    II - Cruft
    Scott Bradner: Note that our working group charter says that we need to decide if we want to pursue a decrufting effort this month.

    Elliot Lear: presentation on de-crufting idea:
    RFC 2026 requires that a periodic review and/or timeout of standards track RFCs. (Although this rarely happens.) He feels that the IESG looks at standards-track documents harder than it might because proposed standard RFCs seem to live forever. He proposes an alternative - require specific positive justification for a standard to continue being considered a standard.
    Questions from Elliot: How many levels (types) of cruft are there? And are multiple levels significant? Historic? Deprecated? Abandoned? Note Margaret's comment that this isn't saving the IESG any time, go look at something else, please. There's a lot of work we need to do on roadmaps and ISDs - that's for sure
    "Valuable in a diminishing market" - it's not just cruft, it's antique analysis We need to think about stalled stuff versus new stuff ("no new cruft")
    "Historic" is an ambiguous designation - no one cares or active warning sign? or something else? Good to review documents, but lots of controversy any time we try to look at a specific document. Maybe not binary/categorization - maybe document-by-document

    Scott Bradner: Does this work matter if we do ISDs?

    Elliot Lear: Maybe we can start decrufting before we start doing ISDs? Go forward as experiment and consider results at Paris IETF - do an Internet draft with a list of documents and a short statement about "why"

    Scott Bradner: Sense of room - Should we consider a cleanup process with self-organizing group working on the draft? Sense of room is "yes."
    Scott: OK we'll proceed. We'll delay the charter milestone for the decruft process document itself until we see results.

    Volunteers? Talk to Elliot in the hallway...

    II - labeling standards
    John Klensin: Current standard designations are not useful, we don't have stable references for most IETF protocols (RFCs, sure, but not protocols!) Propose "Internet Standards Documentation" This idea seemed to have buy-in in San Diego - we'll look at examples today, WGLC after update? Note that if we do ISDs, it's not clear we should continue with updates to "the Standards Track" The last working group milestone still needs to be updating our process BCPs - we still need to say what we do, and do what we say we do. Will this really take until the end of 2005? Some of us hope not!

    Some questions
    A/ Do ISDs have their own maturity levels? Would ISDs explicitly call out the maturity level of documents that it points to? But our maturity levels are way underused now. ISDs text may take over maturity levels, obsoletes, updates, metadata, etc. Major value of ISD is collecting things, maturity levels don't matter as much as the collection feature. We may have "implied maturity levels" by pointing to interoperability reports, etc. You'll need a process for drafting, reviewing (this question matters but we'll talk about it later).

    Sense of room is that ISDs would not have maturity levels.

    B/ Are ISDs only for STD-level RFCs?
    Are ISDs required for every PS? Who is motivated to produce and maintain them? Somebody better be, if ISDs become the way we refer to our standards!

    Sense of the room is that we can produce ISDs for documents at entry to the standards track.

    C/ Is this part of normally producing a document? Format has to be dead simple because everybody has to produce one. At least the MINIMUM needs to be dead simple. How does last call work when you have multiple unrelated efforts updating the same ISD? Knowing that would be a huge step forward, and a far better use of IESG time than other things IESG spend time on.
    Do ISDs get Last Called?

    Sense of room is "yes". But we need to make sure we don't end up with two or three times the number of last calls! Don't think we will, but need to watch for this. Can update maturity levels more easily because they can just be a statement in an updated ISD, instead of a whole new RFC.

    D/ Normative and Informative sections of ISDs?
    We've given warnings of potential changes in RFC text today - and the warnings live forever, right or wrong.
    "If an ISD contains non-normative references, they shall be clearly identified".
    Q - Is this Host Requirements for one protocol? Scary - slippery slope!
    Q - Remember the poor non-IETF purchasing guy reading these things!
    Q Should we include commentary about what was done and why?
    A - Don't require this, but don't make it impossible, either!
    Q - "Normative" is overloaded? Rat-hole!
    Q - how would we do an ISD for "the web"?
    Q - Make normative references to non-IETF documents? (ASCII s an example)

    Sense of the room was that an ISD could include both Normative & Informative references.

    E/ Confirmed errata? Currently goes for expert review or IESG review, or replaces with new RFC. Trying to make "trivial yet normative changes"
    - at least they are last called... extreme example is typos, but we've had the wrong range of testing addresses before, which changed meaning
    Q - Rethinking errata is good, but it's a side issue - we're trying to define what defines a standard.
    Q - We should be defining the minimum framework for ISDs here, not every possible thing in an ISD at this stage of the game. We won't figure that out here, anyway.
    Q - Making profound changes to the way we define standards should be done incrementally - don't go for the end zone now.
    Q - Stuckees for significant ISDs won't do them more than once - don't keep changing the rules and keep going back to the stuckees.
    Q - Like the flexibility of ISDs - we won't even fix full standard errors because there's no energy to do so. There's no energy to revisit security considerations. This makes our lives better.

    Sense of the room question "Can an ISD make changes to text of underlying documents?" Sense of the room is "yes, half, no, a few"

    F/ It's OK to make a normative reference to ASCII with a specific version number, etc? We can say "or a later version", or "use this version only"?
    Q - Needs to be specific and "long-lived", same as current RFC-Editor practice.

    John will bring the remaining questions to the list.

    Sense of the room is "yes, with no no's".

    III - Naming RFCs
    Jonathan Rosenberg: Industry usage of "RFCs" is disconnected from our usage - they think RFCs are "the document series of the IETF".

    In response to a question, Bob Braden said that 5-6 percent of recent RFCs are from "outside the IETF,"

    Jonathan Rosenberg: Very difficult to differentiate these RFCs, MGCP as example - big industry protocol, lots of extensions, but we didn't produce it! We were trapped by MGCP and Megaco being in the same document series. Now even the ITU thinks that MGCP is an IETF standard, even without any security considerations.
    Proposal strawman - RFCs require IETF process, other documents are called something else.

    Q - RFCs have wisdom, but not all the wisdom.
    Q - Sue people who call MGCP an IESG standard?
    Q RFCs predate IETF - can't undo history.
    Q - Need ISDs and enforcement to fix this.
    A - ISDs help and aren't enough.
    Q - Current policies allow MGCP to live forever. This is a de facto standard, and we can't stop this.
    Q - The Internet Draft tries to fix three different problems with one solution.
    Q - Fixing people being confused about our standards takes more than this draft.
    Q - If a working group fails and a draft has value, the RFC Editor SHOULD be able to publish the drafts.
    Q - This is a complex problem, this draft just scratches the surface...
    Q - What about April 1st series of RFCs? Include an MGCP April 1st document in the apparent series?

    Allison Mankin: Can't wipe out RFCs PLUS REFERENCES. The brand is shot. There's no way to get back. RFCs aren't a strong brand, but marketing is a strong consideration...

    Q - People don't implement because it's an RFC, they implement to solve problems. Changing the labels won't matter.
    Q - It's not marketing, it's about procurement.

    Allison Mankin: It's really hard to make an RFC sound like it DIDN'T come from a working group! We need to institutionalize the way we deal with these problems.

    Scott Bradner: Need more discussion on this draft - keep it in the charter, keep active on the mailing list.


    Decrufting the Cruft
    Whats in a Name: RFC