Last Modified: 2005-05-19
| 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 |
|
NEWTRK Minutes IETF-63 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 Chair: 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? Chair: - 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. Chair: 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 Chair: - 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. - SHOULD THEY BE ABLE TO CONTAIN NON-AUTO-EXTRACTED/AUTO-GENERATED TEXT? 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? Chair: 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? Chair: 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 Chair: 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 Chair: 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. END OF SESSION 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. |