2.2.2 New IETF Standards Track Discussion (newtrk)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN 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: 2005-02-09

Chair(s):

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

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

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

Internet-Drafts:

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

    No Request For Comments

    Current Meeting Report

    IETF-62
    NEWTRK WG
    Thursday, March 10 at 1530-1745
    ===============================

    CHAIR: Scott Bradner <sob@harvard.edu>
    SCRIBE: Spencer Dawkins <spencer@mcsr-labs.org>

    AGENDA

    I - Introduction & status - chair

    We are one week away from end of WGLC on ISD document.

    I did not WGLC cruft yet, will discuss moving forward here.

    We are not worrying about the number of stages in the standards process (even though that is what caused this WG to be formed), because if we go the ISD route, it may eliminate the need to worry about the status of individual RFCs.

    II - discussion of ISD proposal - John Klensin
    background reading:
    draft-ietf-newtrk-repurposing-isd-01.txt
    draft-ietf-newtrk-sample-isd-00.txt
    draft-ietf-newtrk-sd-00.txt
    draft-ietf-newtrk-sample-isd-stdproc-00.txt

    We went though a number of issues with the ISD document at the last meeting, the current ISD draft captures all the discussion John could capture. Since publication of the revised ID John did not see comments that require document changes - are there questions? Comments? Are we ready to go?

    Since we don't want the ISD series to contain IETF process BCPs, John so proposed a SD series ("Standing Document") - need to decide what we want to do about this, not obviously within our chartered scope.

    We need a DTD for these documents, if we're going to keep them in XML. The IESG needs to wade in here, because they care more than we can care about the details - if this is the plan, we need to start punting to the IESG now

    Brian Carpenter - what are you punting to the IESG? Not designing DTDs, surely? Defining what they should do?

    John Klensin - That's basically the problem. What sections, what they should contain, etc. We've gotten individual feedback from IESG members that isn't consistent.

    Eliot Lear - we're supposed to decrease the work of the IESG, not increase it. We need a liaison, and it needs to not be Brian. We need to ask "are we keeping the right information?" Let's get this feedback before doing the detailed work.

    John Klensin - If we need arbitrary IESG decisions, it would be more efficient to let the IESG make them on their own

    Harald Alvestrand - The IESG tends to defer complicated questions. We can probably ask "do you agree that X is true and Y is false?" Be as specific as possible. Don't ask them to think about what they really want.

    Brian Carpenter - Let's conspire on questions with binary answers, sometime in the next two weeks.

    John Klensin - We don't want to cycle for very many more months without feedback.

    Dan Connally - XML DTD for what sort of document?

    John Klensin, we've discovered that a small number of categories about unlinked RFCs isn't useful and linking with STDs is too late. We've done a lot of iterations, but that's the waterfront. We're looking for a real document series, not a bunch of RFCs. The ISDs contain prose about the referred-to RFCs.

    Eliot Lear - did not find serial number in the current draft. What about maturity level of ISD versus maturity level of RFCs referenced?

    Scott Bradner - would like to postpone this discussion (on maturity levels of ISDs).

    Bob Braden - what do we need to do before passing to the IESG? Granularity is a real problem and needs to be addressed in the ISD draft. Taxonomy of the problem space, or some part of the problem space, is needed.

    John Klensin - conclusion of WG is that we can't get a unified theory. We can do examples.

    Bob Braden - I'm asking for running code.

    John Klensin - Check the example documents - there's no way to answer this question in general.

    Eliot Lear - Bob is asking for some more specific use cases

    Spencer Dawkins - Use cases are not easy - and don't need to be serialized with this discussion. It would be good to figure out how many ISDs SIP is, but don't wait on this - the SIP chairs think this will be hard.

    Scott - Any objections to moving this forward?

    Bob Braden - is this a BCP?

    Scott believes so.

    Bob - Experimental?

    John Klensin - we don't have process experiments except for July14th RFC. This could be a process experiment, but John is concerned about "going back" if we decide NOT to go forward.

    Scott - IESG would be mandating that WG chairs "do the right thing" - going back will be funky.

    Brian Carpenter - using Experimental doesn't feel right - BCP doesn't feel a lot better, there are problems with the labels. Informational? No level of approval, and people don't read Last Calls for Informational carefully. We'll propose BCP and can go to Historic if we have to.

    Eliot Lear - Backing out is difficult because the other label is STD - this won't multiplex well with ISDs. Maturity levels still need help?

    John Klensin - We cycled with no helpful input last time - we can solve this fast or tell the IESG to figure it out, those are the options.

    Scott Bradner - We can have "soft" labels - "has been implemented", etc.

    John Klensin - If ISDs have the lowest maturity level referenced that solves one problem.

    Scott Bradner - but this means all ISDs will be Proposed Standard, and that's the problem we have now. We have running code that maturity levels aren't used anyway.

    Brian Carpenter - Actually like not having mathematical relationships based on maturity levels.

    Harald Alvestrand - ISDs talking about maturity levels makes sense, having maturity levels doesn't.

    John Klensin - Does this document queue up behind decisions about maturity levels? We hope not.

    Eliot Lear - Maturity statements make more sense than maturity levels.

    Melinda Shore - This is a boffo idea, totally support it, one caveat - we need relatively uniform descriptions

    Scott Bradner - Does anyone think ISDs should wait for maturity levels?

    Eliot Lear - If the purpose is to ask the IESG if we're doing the right thing, we don't have to wait, but if we're nailing things in stone, we need to have some clue.

    John Klensin - Should I just take maturity level of ISD out of the draft?

    Eliot Lear - did we also agree that we would provide descriptive text? But this is about the referred-to RFCs, not about the ISD. Would like to see applicability.

    Scott Bradner - We will forward request for processing with one change after WGLC finishes. This will be a normal request for publication, but we expect feedback from the IESG. If they say "yes", they say "yes".

    Harald Alvestrand - Will the request for processing include a DTD?

    Scott Bradner - We don't have one now, so the answer is no.

    Dan Connally - Is the reason there isn't a DTD because it's hard, or no one knows how, or ...

    John Klensin - We don't need a DTD until the IESG knows what they want, at least not more than a skeleton. We also need to scrub explicit placeholders from the ID, including the cruft work.

    Bob Braden - Is it the expectation that when this is adopted, RFCs will no longer have maturity levels?

    Scott - We'll stay with the current mechanism for pragmatic reasons, until we get a better offer - we'll just say "standards track".

    John went through the rest of the placeholders...IESG can put anything in an ISD they feel to be helpful, right? Seems to be "yes". We've discovered that we need a place to store accumulated experience, that's what we're trying to accommodate.

    Bob Braden - We have a lot of experience about our inability to foretell the future - IESG has a freeform field to extend this mechanism, and that's a good thing.

    Eliot Lear - There's a difference between having a freeform field and having a freeform document.

    Harald Alvestrand - I thought it was obvious that the working group was going for a DTD when they chose XML, so I can start writing text when this is approved.

    III - report and discussion on the anti-cruft effort - Eliot Lear
    background reading:
    draft-ietf-newtrk-cruft-00.txt

    We've been running a cruft experiment since the last IETF. There is cruft out there - we covered this last time. We created a list of all PSes numbered under 2000 and discussed them on a mailing list, asking for anyone to provide any reason why it wasn't cruft. There was barely even a laugh test. We did outreach to find other people, and we're asking again here. We have 57 documents on the current cruft list, out of 119 that we started with.
    Cruft classes - PEM, Whois++. Token Ring, Appletalk, Novell, X.400, X.25, plus MIBs for cruft.

    Pat Thaler - IEEE does five-year reviews, and Token Ring recently passed in IEEE - this is good enough for us.

    Elliot Lear - Telnet docs were removed from the cruft list.

    Pekka Savola - We don't have a clear idea what "making something Historic" means - some people think if a protocol is even in use somewhere in the universe, we shouldn't declare it cruft.

    Scott Bradner - If the criteria is that "cruft" isn't what we would recommend today, should MIBs be on the list if there's no alternative MIB? Obsoleted isn't the same thing as Historic... There are three reasons things became Historic - replaced, obsolete, or a really bad idea - this doesn't help at all.

    Elliot Lear - Other positive output - some documents will be revised, etc. How should we do more outreach? Should a draft detailing what is cruft be Informational or a request to the IESG to remove these documents? Or words for ISDs?

    Spencer Dawkins - Is 57 a big enough number? I thought we had more cruft than this - others? Also - please don't produce a bunch of ISDs about cruft- that's the last thing we need to move ISDs forward!

    Melinda Shore - 57 isn't that bad - we don't want to throw out too much.

    Pekka Savola - The IETF Announce list would be enough outreach.

    Bob Braden - OSI protocols were on the list, and X.400 probably didn't die...

    Melinda Shore - We can do more outreach, Bob is right, and the question of how to filter stuff out is a hard one - we can get input from others.

    John Klensin - ITU is considering bringing back X.400 distinguished names to solve the DNS problem...

    Brian Carpenter - IBM's office I visit has only token ring, we do need to be careful.

    Scott Bradner - A MIB is different from a protocol - the MIB will be in use as long as a device is on the net.

    Pekka Savola - is there any problem with non-cruft referencing cruft? There aren't "normative references" in these older documents. What about Informational? that would get rid of a lot of more...

    Harald Alvestrand - the reason to obsolete X.400 documents in the IETF isn't because no one uses it, it's because no one cares what we said anymore.

    Pekka Savola - The criteria could be "no one has energy to revise this document."

    Eliot Lear - We could also go look at Draft Standards, but we are supposed to be thinking about the process of going to Draft Standards anyway. I'm planning to spend another month looking for authors and doing outreach. If you have contacts/e-mail addresses for someone who's interested, please send them to me.

    Scott Bradner - What is a plan for going forward?

    Pekka Savola - any assumptions about Informational RFC versus actual request for action?

    Scott Bradner - Show of hands - Fun exercise and move on? Publish the list? Request moving documents to Historic? Last two options got about equal support in the room, we'll take this to the list.

    Brian Carpenter - the second option needs justifying.

    Melinda Shore - eventually this needs to go to the IESG, but it's not ready yet.

    Doug Otis - We have a massive RFC Index and it's hard to figure out most recent document - can we have a cruft-free index, at least?

    Bob Braden - I don't think we should just forget about this, but ISD will make this irrelevant, so put your energy there, unless the document is harmful to the Internet.

    John Klensin - I'm concerned that we do as little as possible to add work to the IESG - ISDs will make these documents irrelevant - I should remove the ISD text pointing to cruft, right?

    Scott - Right, and we can move discussion about alternatives into an opinion.

    Melinda Shore - There's another step that needs to happen before we go to the IESG - we have to do a Last Call to move to Historic anyway. The mechanism to identify cruft can use some refinement.

    Eliot Lear - I agree that the number of documents that can be crufted being only 57 means the document classification is actually being maintained. We can wait on the ISDs and come back to this if we have to.

    Pat Thaler - I'd rather have choice 1 than choice 2. Publishing another RFC that calls Proposed Standards cruft will be invisible and people will continue to use them.

    Harald Alvestrand - If we don't declare these documents Historic, we should abandon the concept of Historic. Declaring something cruft by not issuing an ISD is pretty obscure.

    Eric Grey - Just making documents Historic doesn't make them go away. The advantage is that this does raise the visibility of the document's status.


    Scott Bradner - we've used Historic to tag really bad ideas – it would be bad to lose the ability to do this.

    John Klensin - what path are we going down? I thought we would issue a 57-document ISD and bail all of them out.

    Harald Alvestrand - that would work for me.


    Scott Bradner - There is no support for abandoning the crufting work, we're still going forward.

    IV - wrapup - chair

    Where to go next? We could have ISD draft and cruft done by Paris. Look at the labeling of RFCs? Maturity level, and tagging non-IETF documents. ISDs could make RFC maturity levels irrelevant.

    Bob Braden - I'm confused - I thought the label on the RFC reflected the standards process - is this changing?

    Scott - Revising RFC 2026 rules on RFC maturity levels can wait until we're sure we need to do the work on this at all. We are going to have to revise the standards process eventually, but we can wait to see which way we need to revise it.

    Bob Braden - If you have a standard and want to extend it, is another RFC added to the ISD? Or a new ISD might reference the old one, or...what's the process for deciding what ISD an RFC goes into when a standard changes? RFC Editor needs more guidance here.

    Brian Carpenter - I agree and want to say it differently - this is how we direct someone to the real SMTP specification instead of the full standard one. We can freewheel here for a bit before redoing RFC 2026. Clear way to identify non-IETF RFCs? If we have ISDs, and we are extremely clear what a standard is (an ISD), this probably doesn't matter.

    Bob Braden - Not All RFCs Are Standards - actually, "NO RFCs are standards" - correct.

    Scott Bradner - Defer this work, too? No objection in the room. All of the rest of our objectives are deferred, and we won't meet in Paris.


    Slides

    Agenda
    Cruft Update