Last Modified: 2004-11-01
| 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 |
|
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 AGENDA 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. |