2.2.3 New IETF Standards Track Discussion (newtrk)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www2.sobco.com/ietf/newtrk.htm -- Additional NEWTRK Web Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-17

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

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

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 topics: 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

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

Goals and Milestones:
Jun 04  Publish initial Internet-Draft(s) describing a revised IETF standards track
Mar 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
  • No Request For Comments

    Current Meeting Report

    IETF 60 NEWTRK Working Group Minutes IETF

    New IETF Standards Track Discussion WG (newtrk)

    Thursday, August 5 at 0900-1130
    CHAIR: Scott Bradner <sob@harvard.edu>
    MINUTES: These minutes were created by Scott combining notes taken by Spencer Dawkins <spencer@mcsr-labs.org> with the session jabber log Peter Saint-Andre.

    Agenda Bashing: Chair

    No agenda bashing took place                 

    WG status:  Chair

    The working group status is actually sort of muddled. Scott thought that we were getting close to consensus on a two-step standards process but mailing list consensus collapsed - we've only had about 15 posters over the last month, only 8 in the past 2 weeks - hard to gauge consensus with such a small sample size

    We've officially missed our first milestone (in June), but we do have a  WG landscape draft (it's just not the one we're supposed to have)

    Discussion of current proposals:  David Black

    Black/Carpenter ID draft-ietf-newtrk-proposals-00.txt
    • outline various proposals without making recommendations
    • tease out common and reusable ideas from various proposals
    • identify pros and cons
    • metrics for success? - improving interoperability, getting stuff done,
    • faster, increase use of higher standards steps, make IETF more attractive
    Larry Masinter - metrics should be correlated with our goals - most of these metrics are timeliness, ignoring quality goals, for example

    Scott Lawrence - would like to see metric - reduce "conform to this ID" citations

    Spencer Dawkins - metrics for success are hard, for failure easy (Harald Alvestrand said this in ICAR)

    Aaron Falk - move kind of review that we get from IESG earlier in the process

    Scott Bradner - i.e., less bounce-back from IESG to WG?

    David Black - Less cross-area discusses?

    Brian Carpenter - we're close to discussing ICAR metrics here

    Bob Braden - standard quality may be inversely proportional to document length

    Eliot Lear - what does that mean in terms of what we're doing here?

    Larry Masinter - concerned about metrics over which we have no control eg., marketing references by marketing people e.g., if status of document doesn't reflect status of protocol

    John Loughney - how useful is this? Not all Internet drafts are the same - WG drafts?

    Brian Carpenter - Length of time for WG drafts to cycle from 00 to RFC.

    Larry Masinter - things come into the IETF at varying levels of maturity - harder to measure

    John Klensin - need to be careful about success criteria metrics, because they are easy to game - peer SDOs have already tripped over this

    David Black - Rough consensus on the list that a standard is not forever, no matter how many levels we use - we're never through

    Scott Bradner - i.e., can cycle in grade, not just progression through stages

    Keith Drage - IETF doesn't know how to incorporate errors and extensions - when you stop changing a protocol, it's obsolete

    Brian Carpenter - don't know how to handle trivial errors, either

    Larry Masinter - Protocols change, documents don't (e.g., people post changes at a website or in a research paper without coming back to the IETF)

    Eliot Lear - some documents get old and crufty - stay tuned for details

    Brian Carpenter - the words "old and crufty" are not in the current draft, need to be added

    Scott Lawrence - names of levels are at best ambiguous and at worst misleading - having both "Internet Draft" and "Draft Standard" don't work - we ought to fix the names if nothing else

    Scott Bradner - related nit: we get IPR disclosures that say that 'X will happen if protocol becomes an IETF Standard'

    Larry Masinter - name changes are least important change - want to encourage documents to be revised to match the protocols

    Keith Drage - revision vs advancing in place is confusing - "moving to next level" is problematic, need to be more rigorous

    Scott Bradner - depends on the scope of changes

    David Black - Proposals on the table -
    1. clean up our act,
    2. go back to 2026 as written,
    3. prune levels to two,
    4. whack everything to one level,
    5. declare victory and don't change a thing (and document differences between what we do and 2026)
    Common ideas - snapshots, document what we've learned from implementation and deployment, version numbers, better process documentation and tracking

    Brian Carpenter - process documentation bleeding into shepherding, etc. - need to coordinate

    Aaron Falk - what happens in the working group and what happens to the existing body of standards - need to think about both at the same time - this could be disruptive

    Keith Drage - what kind of tracking of "good" vs "bad" documents or good vs. not so good, e.g., is tracking internal or external?  needs to be reflected by something on the cover of the document so can be understood outside the IETF

    Eliot Lear - I propose that we take "just revise 2026" off the table

    John Klensin - note that defacto this means one standards level

    David Black - so you want to take proposal 2 off the table? (room - "noooooooooooooooo")

    Larry Masinter - reality does match the written record, so first step is to tell the truth about where we are today

    Paul Hoffman - VPN consortium has to implement IETF specs - if we do slash and burn, outside world will be very happy, levels confuse vendors outside the IETF

    Brian Carpenter - would those happy people want version numbers?

    Paul Hoffman - absolutely - interoperability register, too

    Kurt Zeilenga - not enough consistency in our current processes across working groups to declare victory

    Scott Bradner - process varies between areas, e.g., Routing Area has different criteria

    Aaron Falk - snapshots could mean different things in different WGs

    Larry Masinter - how well the proposals motivate individuals to write true statements about the protocols

    Keith Drage - interoperability register looks like a very good idea - would anyone contribute?

    Brian Carpenter - we didn't put pros and cons for version numbers in the draft, and we need to

    David Black - Questions: any major options missing?  Do nothing? Can we take this off the table? Without even documenting changes?

    Harald Alvestrand - if we do nothing, we can stop now

    Brian Carpenter - let's add a section on really doing nothing - advantage of removing hypocrisy

    David Black - Are descriptions accurate?

    Brian Carpenter - I would like to see discussion of pros and cons on the list

    Larry Masinter - pros and cons aren't right - will send text to the list

    Paul Hoffman - for whom are we making changes? There are two audiences, so could have two pros/cons lists

    Brian Carpenter - want to refine pros and cons before we make choices

    John Klensin - proposals overlap in funny ways -

    Peter - decompose proposals into specific pieces? Maybe "yes" if we can keep from screwing it up

    Keith Drage - need reality check on proposal components to make judgments

    Spencer Dawkins - take stuff off the table if we can at this meeting

    John Klensin - goodness as a criteria will fail - someone will like anything, but people have to do the work, even though some things on the list are evil - cost-benefit is harder and smarter

    Larry Masinter - interoperability matrix doesn't evolve - too static - make it part of another process

    Aaron Falk - we've sidestepped comments on these proposals at this meeting

    Brian Carpenter - would like to see discussion on the list, because this draft is a two-brain dump, not a WG document

    Adding a layer of indirection to standards naming: Klensin

    draft-klensin-newtrk-std-repurposing and

    John Klensin - Two proposals, started off in different places, overlap a lot

    First some history - We adopted three document series for standards track with one set of documents - BCPs and STDs exist only as an index, and this creates problems that prevents much use of STDs

    STDs should be real documents, which can be referenced and which can capture changes over time

    Two John proposals overlap a lot - difference is that John Loughney is doing web pages and John Klensin is doing stuff in documents

    We can't tell people to implement 2821 (PS) instead of 821 (full standard).

    Aaron Falk - if we are terrible writing AS docs, why would be good at writing these new STD docs?

    John Klensin - the question is how we document clearly and publicly what the IETF was doing when, for example, 2821 can't replace 821, except in protocol action notices.

    Keith Drage - how will this help me from an external referencing point of view? Problem is that we need to refer to things long before they are full standards - proposal assigns STD numbers at Proposed Standards.  This might help with referencing something like TCP

    Scott Bradner - actually TCP is now a poster child for this problem

    Keith Drage - I'm more interested in things that are not yet standards, such as SIP

    John Klensin -  Something I did not mention is that a standard number goes on something the moment it goes to proposed. This doesn't require changing the standards process. This makes it possible to say things like "SIP is becoming like TCP and here is the list, but here is what you need to pay attention to."

    Bob Braden - we're creating a new namespace for standards, and this makes a lot of sense (allows version numbers). RFC numbers are document references, not standards references.

    John Klensin - This is an attempt to separate documents registry issue from the standards issue - two issues: (1) standards namespace (2) boundaries of labels

    Aaron Falk - there's a connection here with the PROTO team - need to coordinate - trying to get WG chairs to write protocol piece of action statement

    John Klensin - the proto team effort is probably an important component here

    John Loughney - I think John Klensin and I are attempting the same thing how much do we capture and how do we do it? e.g., never clear how updates and obsoletes work

    Scott Bradner - need to say HOW a document updates another

    Larry Masinter - working group splits the protocol into several documents, and some of the critical details may be missing - need to point to Informational, IDs, mailing list postings, etc. - and we need examples to think about this more

    Keith Drage - where are we headed, on document types? Is this a bibliography, a document tree, a profile ... created when the IESG approves a document? - these documents become a byproduct of IESG protocol actions.

    John Klensin - this would become part of the process by which a protocol action happens  - errata are a procurement problem and a lawyer problem - ASes were supposed to handle this, but they are rarely used. "Must conform to STD 75 as of this date/version". And STDs have abstracts, just like other documents have abstracts.

    Scott Bradner - Another common experience is that a document has not addressed a certain concept and would need to be addressed in a revision, but there has no way to document those so that we remember to address it when the doc is revised

    Bob Braden - John Klensin pointed out that errata on standards are standards-track issues, so they've been pointing these to the IESG

    Aaron Falk - don't we need version numbers if this is a procurement-world concept - or at least dates and tracking history

    John Klensin - conformance with STD doc as of a particular date

    Eliot Lear - I like the idea, this is obvious in a web-based world, draft is verbose (and will get longer with examples).

    Larry Masinter - these documents need to be more prominent than RFCs - RFCs contain pointers to current STD locator - what if the RFC gets reused in more than one STD?

    Bob Braden - it would be useful to separate namespace engineering from mechanisms for publishing, so we can make progress - is SIP a standard, or are there pieces? - need to be clearer about figuring out what goes in a STD.

    Scott Bradner - "standard 35, or standard SIP?" frequently our standards are known by a colloquial name

    John Loughney - what can we break out, in order to make progress? Make a draft that's an example?

    John Klensin - the proposals differ in maintenance models, but overlap a lot. John Klensin concerns about web pages (as major mechanism) and maintenance teams (which become self-preserving). My personal opinion is that proposals address same general space and main ideas are compatible. Repurposing STDs does not change basic way in which we work, only how things are documented -- may speed things up without more risk. Maintenance teams and web pages are a poor standards technology, especially for procurement -- bad experience in IETF and elsewhere with standing interpretation and revision committees.

    John Loughney - someone has to define what TCP is and produce these documents. Don't care about how or where, and recognize procurement issue. Understand concerns about maintenance teams, and know we have to get the work done someplace.

    John Klensin - it's worth fleshing out TCP, but not worth fleshing out the full set of STDs (certainly not the full set of proposed standards). Somebody has to decide it's important enough to tie proposed standards together.

    Peter - we do non-authoritative work with technical publishing

    Keith Drage - if these are to be usable, these must carry a level of authority -- same or greater than the STD document

    Larry Masinter - what about application-level protocols - HTTP with cookies, etc? HTML? A browser? what's the "STD"? - every document is discrete until someone decides documents go together and does the work.

    Bob Braden - don't call your new space STDs - need a new namespace. Haven't been able to retrain people to use STD numbers - at least take RFC numbers out of standards-track document - mistake to call new this STD, perhaps ISN (Internet Standard Number) references.

    Kurt Zeilenga - what about STD version compatibility? "standard as of a certain date". We do this referring to standards from other SDOs now.

    Scott Lawrence - need for non-normative references within the STD - e.g., HTTP with cookies. - may be work that hasn't even happened yet.

    This proposal slides toward taking over AS functionality as well.

    Is defining the labeling a function of this working group? Labeling problem spans all proposals. This proposal affects the importance of other questions the working group is thinking about.

    Keith Drage - this improves the external referencing issue a lot.

    Scott Bradner - Sense of the room? Should this work should be done in this working group?

    Kurt Zeilenga - this seems orthogonal to defining what the standards track should be

    John Klensin - you are right, but that does not imply it is not good to separate that work

    Scott Bradner - if we have something like this which points to a set of documents, then the importance of the levels is reduced

    John Klensin - can even say "we have high confidence in this standard except section 7 and there is an I-D that is working to address it" etc.

    Scott Bradner -  hum: should work of this ilk be done in the WG? (strong hums for, no hums against)

    John Klensin - can others help by providing real examples? (please?)

    Cruft Removal: Lear/Alvestrand

    Eliot Lear - Daytime, time, host access protocol, hello, SLIP, IP over SMDS - these are all full standards. Draft standards and proposed standards are just as bad. And some have serious security problems, etc.

    Some fruit is low-hanging, some is more controversial.

    Still used? Would you want someone to use the concepts again?

    Is it safe to use?

    John Loughney - it's currently much harder to remove things that are dangerous (because another RFC is required) - but people reference RFC numbers and don't know it's been deprecated.

    John Klensin - this points out why the labeling discussion needs to be part of this WG discussion

    David Black -  difference between "waste of time" and "hazardous to your health"

    Elliot Lear - How to remove? Ad hoc committee? Working group? w/IESG approval? 2026 requires IETF last call.

    Current proposal in ID

    Also includes DS, PS, BCP.

    Larry Masinter - these docs can be short and are not that hard to do

    Bob Braden - Jon Postel said "standards are forever" - moving to historic means "egregiously bad". Maybe this was the product of a simpler time. Some of the oldest STDs were grandfathered as STDs in the first place when the standards track was created.

    Eliot Lear - "Historic" has come to mean "dangerous". But some of these are not dangerous, just old and no longer in (wide) use. What if there are a lot of historic documents?

    John Klensin - do we need new levels for "bad" and "stupid"?

    Elliot Lear - why do this at all? parts of the community are concerned that once something passes to PS/DS/STD, it's there for a long time, which leads the IESG to be overly careful about advancing things to those levels.  Let deployment experience dictate lifetime of a standard. This discussion applies to standards-track document only.

    Keith Drage - this movement takes effort - is moving worth the effort? we might think it's dangerous, but someone might be using it in a restricted sense?

    Scott Bradner - their use might not be as restricted as they think if it is going over IP

    Elliot Lear - The main benefit is to introduce a release valve.

    Kurt Zeilenga - "informational" might be an appropriate demotion, too - prevents standards-track normative references, forces people to update/fix documents.

    John Klensin - what about the forever-ago proposed standards we have now? Automatically advanced? "Hasn't killed the Internet yet." If we pass through killing, we should pass through advancing as well.

    Scott Lawrence - Time is not as important as having an orderly process to address these matters.

    Elliot Lear - only reason for time perspective is that we can remove the notion that proposed standards live forever

    David Partain - I think spring cleaning in standards docs is a good thing that will force us to learn some surprising things about our process, but we need to do so in an open way

    Harald Alvestrand - This is the most light-weight process we (Elliot and me) can imagine for moving things to Historic. If we decide not to do this because it's too much work, we should stop talking about making things Historic - because it won't be done, we know that, and we should stop fooling ourselves.

    Elliot Lear - Harald and I would like to do this and any change to Historic would happen only after IETF Last Call and IESG approval

    Keith Drage - ETSI added historic - this is contentious - The Last Call matters.

    Elliot Lear - document why standard is thought to be old and crufty, put through IETF Last Call, if possible incorporate dissenting opinion

    Scott Bradner - involve authors if possible.

    Scott Bradner - humm if think it's a good idea for WG to pursue?  (Sense of room is "yes")

    Scott Bradner - Autoupgrade also?  (Not a strong sense of the room. Go to the list.)

    Valid HTML 4.01!


    A Different Access and Maintenance Model for the Standards Track
    Proposals for a New IETF Standards Track
    Letís Talk Old and Crufty