2.2.1 New IETF Standards Track Discussion (newtrk)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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: 2005-05-19


Scott Bradner <sob@harvard.edu>

General Area Director(s):

Brian Carpenter <brc@zurich.ibm.com>

General Area Advisor:

Brian Carpenter <brc@zurich.ibm.com>

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
levels for specifications is no longer being used in the way that was
envisioned when the stratification was originally proposed. In
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
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
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
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
Done  Determine if there is consensus to proceed with defining a new RFC cleanup process
Done  Determine if there is consensus to proceed with a new document series to describe and define individual IETF technology standards
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
Aug 05  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
Aug 05  Publish initial Internet-Draft(s) describing a revised IETF standards track
Dec 05  Submit final Internet-Draft(s) describing a revised IETF standards track to IESG for publication as a BCP


  • draft-ietf-newtrk-repurposing-isd-03.txt
  • draft-ietf-newtrk-sd-00.txt

    No Request For Comments

    Current Meeting Report

    NEWTRK Minutes

    Friday, August 5 at 0900-1130

    SESSION CHAIR: Harald Alvestrand <harald@alvestrand.no>
    WG CHAIR: Scott Bradner <sob@harvard.edu>, attending via Jabber
    Notes: Spencer Dawkins <spencer@mcsr-labs.org>

    reading list
    - newtrk list archives
    - http://darkwing.uoregon.edu/~llynch/newtrk/index.html
    - draft-ietf-newtrk-repurposing-isd-03.txt
    - draft-lear-newtrk-decruft-experiment-01.txt

    AGENDA: The agenda was bashed...

    - Brian Carpenter - does "next steps" include drafts for a new standards track?

    - Sam Hartman - SRD and ISD in one big bullet - issues and next steps in one big bullet - Larry's proposal on the list fits somewhere

    - John Klensin - please don't conflate SRD and ISDs - they are different and should we be discussing stuff that's not a draft?

    Chair: - SRD is probably a comment on ISDs, so this could be OK

    - Spencer Dawkins - there are two basic issues that have been raised -
    who will write ISDs, and who will approve them. All other is details.

    - Chair: - We are likely to accept only one proposal of ISD and SRD

    - Chair: - Interest in Larry's proposal on implementation reports? -
    Some interest, but tabled for now

    Interest in one-step/two-step?

    - Brian Carpenter - need to have interlocking proposals that make sense, not fragments

    - John Klensin - happy to start one two-step, but need more drafts on one-steps, no opportunity to do drafts

    - Scott Bradner - need to get metadocuments first

    1 - introduction & status - chair (done via email to list http://darkwing.uoregon.edu/~llynch/newtrk/msg01255.html)

    2 - discussion on the issues with ISD proposal raised by the IESG and others

    o What is an ISD?

    - About half the room has read the ISD drafts (good work!)

    - We are confused - both implementers and procurement types can't refer to what our "standards" really contain

    - ISDs become the standards - RFCs are no longer standards

    - as per plenary - very difficult to talk about concepts at the IETF - always too much detail or too little, never "just right"

    - Brian Carpenter (channeling IESG comments, as IESG chair) - proposal was discussed at the retreat, slides plus document

    - Proposal doesn't explain what problem is being solved - several IESG members do think metadocuments is the right way to go

    - SRD doesn't have the same problems - because it's not meeting the same requirements

    - ... and then IESG went into BOF mode, and ...

    - Ted Hardie - two problems mentioned by Spencer, plus who is going to read these documents? Our standards process is now actively in the way of our specifications process - how to iterate? This is really moving to a different model for standards, but not for specifications, and specifications are more important

    - Leslie Daigle - like metadocuments or overviews, need to be clear about whether this is lightweight or heavyweight - reviewed? normative? Need to pick one answer

    - Pete Resnick - have followed up with Ted after the retreat - don't even understand whether new specifications update older specifications very easily - who is the audience? Implementers? Procurement people? then ISDs are appropriate. Other SDOs? ISDs would not be appropriate for particular specifications - but this is not the goal anyway.

    - Alex Zinin - like to step back from IESG perspective - people come here because they can get things done here. Process overhead is a price. The acceptable price is limited. Don't increase red tape. We have applicability statements today, and people aren't writing them - why?

    - Spencer Dawkins - should we be worrying about "standards" at all - IETF-approved specifications, and be done?

    - Dave Crocker - Ted making distinction between specifications and standards - ISD goal is actually tying pieces together. If we care about our stuff gets used, maybe we should help people figure out how to use them. We are never done. How does the outside world take, and work with, snapshots?

    - Sam Hartman - this isn't the biggest problem we've got, but ... I am a proponent of metadocuments, but not ISDs. Would like to discuss concerns I have with ISDs - too much text, updates would be contentious, concerned about ISDs as references in some cases - inter-document references to RFCs, not to ISDs, concerned about errata in the ISD, especially if it's not consensus-driven, and concerned about whether metadocuments are needed all the time.

    - Ted Hardie - believe ISDs would be harder for implementers - the way this is put together, including the errata and commentary, really makes it harder. In really complex cases, we still need RFCs anyway.

    - Doug Otis - database isn't the same weight as an RFC, but it would be useful to have a central location for a set of documents. SRD tries to limit itself to half a page. Concerned that ISDs will get out of sync if there's a heavyweight review.

    - Aaron Falk - Scott is participating in Jabber discussion - need to include him in verbal discussion - Brian will channel Scott - "folklore should be written in RFCs if it's important".

    - M. Tomas Carrasco-Benitez - de jure or de facto doesn't matter for single specifications, but compound documents do matter, and it doesn't matter whether they have the same name or different names. It would be nice if the IETF does have compound documents.

    o Doug Otis - what is an SRD?

    - Flat system is difficult to deal with... Trying to start with ISDs and stay in sync with standardization process

    - IESG has to take a look at SRDs, but SRDs should help their process, not slow them down.

    - Should be a status database for issues tied to documents

    - Not authoritative information - stuff that hangs around in SRDs should become an RFC.

    - Want stable references for IETF products

    - Link to database with partitions (IESG notes, IETF notes, security alerts, ...)

    - Larry Masinter- lot of stuff besides SRDs in the database - where does it come from?

    - John Klensin - SRDs looked very lightweight at the beginning, but are gaining weight - what's the current difference from ISDs? WG approval, IESG approval... did we converge?

    - Alex Zinin - STD groupings not used today - when you refer to a spec, you refer to a specific revision. This isn't useful. There are problems with the standards track, but this isn't addressing any of the problems I'm hearing about.

    - Doug Otis - SRDs do have serial numbers...

    - Sam Hartman - while I don't like ISDs, SRDs provide an interesting starting point for compound documents. I like "very little text" within them. No descriptive text - that's the critical feature. Automated tools are OK, anything more is not helping. Handles the grouping problem, separates out other problems. Going to have a nice long debate about who updates text in the database. SRDs need not cover all documents, especially at first. Don't make them mandatory - run an experiment.

    - Scott Bradner - ISD could use standards action text.

    - Spencer Dawkins - question Harald's statement that we have to pick between ISDs and SRDs - we COULD do both, if the same people don't have to write both and read both - can't go back to nonexistent working groups, so what then? Can't extrapolate from STDs, because we have so few - nothing advances.

    - Larry Masinter - it all boils down to what we get and who does the work.

    - Aaron Falk - does this work without status database? SRDs is lightweight, database is not.

    - David Kessens - very worried about what I'm seeing - we're adding complexity and work, doesn't matter about the details.

    - Dave Crocker - concern for the effort to create these things, but more concern about how they will be used. We don't spend nearly enough time on this.

    who believes there are proposals that are useful? more than believe there is no such proposal in the room, but the people who believe "is no such proposal" also believe "cannot be such a proposal".

    - Pekka Savola - generating something automatically has hope. Anything more does not. Consensus will kill this.

    - Chair: - who believes ISDs are viable? Document is full of options - John doesn't know how to answer this question!

    - Brian Carpenter - assume ISDs are part of the standards process?

    - Larry Masinter - can we have the discussion that was on the agenda before we start asking questions? Have talked to people at his company who read RFCs - key thing is what do we have to do interoperate with the greatest number of implementations?

    - Sam Hartman - would be happy with a mechanism that does not complicate the standards process except when using it adds value. Don't want to get sucked into discussion of grouping text, don't want to have to group things when no grouping is required.

    - Pete Resnick - would be happy with grouping documents that go through the standards process, as long as they aren't required? Sam - yes.

    - John Klensin - ISDs and SRDs are converging, except whether one is normative - <but the room was very confused about which of the alternatives was normative - apparently both would be approved> - we're headed off to a dark place

    - David Kessens - are you sure there is consensus that ISD/SRDs should exist?

    - Alex Zinin - run an experiment?

    - Dave Crocker - suggestion that product manager is a consumer was good

    - imagining useful product data sheets that used BCPs? helping both product managers and consumers.

    - Sam Hartman - this is a valid use of BCP under RFC 2026, and we have running code in OPSEC. Not QUITE the same, but overlap. Support experiments in this space, don't forget success criteria, don't forget incentive to participate in the experiment, need tools support to succeed and avoid too much work.

    - M. Tomas Carrasco-Benitez - name doesn't matter, want to specify what a tender must contain. People know RFCs are standards ("oops!"). Grouping a whole set of documents saves one or two pages in a 200-page tender.

    - Bob Braden - we do a great job of turning out specifications and a horrible job of modularity. RFC database contents are really ugly. I feel really sorry for implementers! I understand concern about additional work, but do see additional benefits.

    3 - future of ISD proposal

    - SHOULD A TYPE OF GROUPING DOCUMENT EXIST? 25 out of 40 yes, 4 no

    - SHOULD THEY BE MANDATORY? <in some cases?> run an experiment? room sense is "no" - use the PROTOS model?

    - SHOULD GROUPING DOCS BE APPROVED? depends on the text they contain? - approved by the working group? - show the IESG a couple of examples? About half the room was willing to say "yes, approve them", but this also includes question of normative text in these documents, and what "approval" means.

    Sense of room is that a lot of people think "yes"

    - SHOULD THEY NORMALLY CONTAIN TEXT? No sense of the room. Get a concrete proposal and discuss on the list.

    3.5 - implementation reports - Larry Masinter:

    - have seen documents generated by IETF participants in an informal way

    - HTTP, WEBDAV - formalize what we already do anyway

    - get IESG out of business of approving interoperability reports they can't verify anyway

    - Sam Hartman - experiments are useful, intersection with 2-step is interesting

    - Spencer Dawkins - is additional work for the IESG still on the table? several IESG types - yes, that's OK - Sam, OK, otherwise we should all be recalled!

    - Pekka Savola - vendors don't want to spend time on implementation reports - we have, like, two reports on BGP4.

    - Bill Fenner - IESG has problems evaluating implementation reports

    - Larry Masinter - come to consensus on form of reports, don't approve reports?

    - Bob Braden - Identify WGs with specs that are excessively feature-rich?

    We encourage Larry to move forward with a proposal

    5 - next steps with de-cruft - Eliot Lear

    - 56 documents still on the cruft list

    - Four alternative ways forward - we need to pick only one.

    - Bob Braden - X.400 non-use? FDDI?

    No one sees a benefit to the community to leaving these specifications on the standards track.

    - ACCEPT RESULTS? Strongest support in the room was for this alternative.

    - DON'T ACCEPT RESULTS AND UPDATE 2026 to match what we do? No support in the room

    - ACCEPT SOME RESULTS and still update 2026? Light support in the room

    - DO NOTHING? Very light support in the room

    - Bert - I've tried this under Fred Baker, killing one doc was a lot of work, got lots of pushback, suspect that it's going to be harder than you think

    We are lying to people in 2026, but we are lying to them about so many other things...

    - David Kessens - this isn't worth the work for the IESG.

    - Pekka Savola - it's mostly individual efforts.

    - Sam Hartman - get the community to chill out about Historic

    Need to do working group last call on this draft. Will publish as working group draft.

    4 - next steps in newtrk, how to discuss 1-step/2-step

    - Brian Carpenter - the goal of this group is to develop a revised standards track. Are we really going to do this?

    - Larry Masinter - remove draft standard approval from IESG?

    - Pekka Savola - modifying that part of 2026 won't matter much, IESG doesn't really review implementation reports now, not really a bottleneck

    - Spencer Dawkins - need to keep implementation engineers engaged - two BOF cycles mean up to 11 months before you start on a specification - all the people that are left are standards professionals.

    - Dave Crocker - if we're going to have more than one stage, we need to think about what they mean - being widely used is helpful to know

    - Alex Zinin - IESG does review interoperability reports, especially in RTG, please do what the charter says and make the IETF a better place.


    Session Chair summary: ISD/SRD/Metadocument discussion
    My sense of the room wrt ISD/SRD/Metadocument:

    - These can potentially be useful (a few dissenters)

    - These need to be approved by someone, not "just written". So they need a process for generating and approving them.

    - Some text is needed in the documents - the smallest thing needed is to describe what technology it tries to cover.

    - It's likely that "less is more" - the SRD initial description sounds less likely to generate controversy (and therefore work) than the ISD initial description.

    - Introducing this type of document should be done via an experiment with "willing users" - something on the order of the PROTO experience.

    Note: These are not my opinions (even though I think they represent a viable way forward). It is what I think the opinion of the room was. But I'll take full responsibility for the formulations.

    Session chair summary - implementation reports
    This is a really short summary....

    - Implementation reports are very useful to the community

    - The IETF has legal reasons not to be seen as "approving" implementation reports

    - Larry's suggestion is to separate the report format from the report content, and to have the IETF approve the report format (what we report interoperability on). Interoperability reports would be filed as "filer's responsibility", as today.

    - The issue of how to "advance" specifications is related to this.

    - The room encouraged Larry to flesh out his proposal into a real proposal

    Session chair summary - Decruft
    My summary (disclaimers apply):

    - The sense of the room is that it wants the document sent to the IESG for a Last Call on a standards action that would move the 56 documents (or whatever remains of them after Last Call comments) to Historic

    - There is still fear that the Last Call will generate significant noise and work for the community, with little benefit

    - We will learn whether that's true by trying it

    Eliot will prepare a new version with this recommendation, and ask for a WG Last Call on it.


    Set of RFC Documents SRDs
    De-Cruft Results & Next Steps