this is the jabber log for the newtrk session held Thursday, August 5 at 0900-1130 PDT (edited to remove the joins & exits and a few unrelated greetings) full log at: http://www.xmpp.org/ietf-logs/newtrk@ietf.xmpp.org/2004-08-05.html [11:01:15] Saint Peter is going to be on shortly to scribe on jabber [11:01:34] Scott's disscussing the "muddled" WG status [11:02:12] SB: thought we were close to consensus [11:02:19] consensus rather collapsed [11:02:27] about 15 posters over last month on list [11:02:32] only 8 over last 2 weeks [11:02:44] hard to gauge consensus with small sample size [11:02:52] we have missed our milestone [11:03:04] supposed to have document with recommendations out by june [11:03:14] we do have WG draft (black + carpenter) [11:03:26] any questions on status? [11:03:30] moving along [11:04:23] David Black [11:04:35] draft outlining proposals [11:04:58] http://www.ietf.org/internet-drafts/draft-ietf-newtrk-proposals-00.txt [11:05:11] discuss pros and cons, not make recommendation [11:05:21] possible metrics for success [11:06:12] increase interop, shorten time to stable spec, reduce time required to document, improve motivation of IETF participants [11:06:29] input from group [11:06:48] Larry Masinter: metrics should be correlated with goals [11:07:00] not clear how these metrics correlate with IETF's goals [11:07:44] SB: do you have suggestion for improvement? [11:08:26] Scott Lawrence: another possible metric is reduction in number of claims that people conform to an Internet-Draft [11:09:16] easier to have quantitative metrics for failure than for success? [11:09:58] Aaron Falk: might be desirable to get IESG-type review earlier in the process [11:10:09] (broad interdisciplinary review) [11:10:21] SB: result would be less bounce-back from IESG [11:10:33] number of cross-area discusses [11:10:50] Brian Carpenter: getting close to ICAR metrics [11:11:10] Bob Braden: success might be inversely-proportional to its length [11:11:42] Eliot Lear: what does that mean in terms of what we're doing here? [11:12:15] Larry Masinter: concerned about metrics over which we have no control [11:12:28] LM: eg., marketing references by marketing people [11:13:05] LM: e.g., if status of document doesn't reflect status of protocol [11:13:27] John L: wondering how useful this is -- there are IDs and then IDs [11:13:38] John L: restrict our focus to WG drafts? [11:13:59] Brian C: number of months between 00 draft to RFC [11:14:42] LM: things come in at very different levels of readiness [11:15:33] Spencer Dawkins: I agree with Larry -- and further, we don't define criteria for becoming a WG draft [11:16:01] John Klensin: we need to be very careful about metrics [11:16:10] could the jabber scribe ask david black to confirm his time issue to the tsvwg chairs - is 10:30 OK? [11:16:25] JK: easy to manipulate any metrics [11:16:51] mankin: yes [11:17:03] David Black: common ground... [11:17:33] WG seems to have rough consensus documents will be revised and re-approved with or without changing level [11:18:57] Keith: how do we incorporate errors etc.? [11:19:19] in other SDOs, once you've stopped changing the standard, it is obsolete [11:19:39] how do we manage trivial errors vs. substantive errors? [11:19:58] Larry Masinter: protocol can change without document being revised [11:20:42] (e.g., people post changes at a website or in a research paper without coming back to the IETF) [11:21:02] Eliot L: corollary: some docs will get old and crufty [11:21:34] Brian C: these words are not in the draft, only on list so far [11:22:06] Scott L: the names of the levels are ambiguous and perhaps misleading [11:22:16] SL: we ought to fix the names if nothing else [11:23:08] Scott B: related nit: we get IPR disclosure that X will happen if protocol becomes a Standard [11:23:27] Larry M: name changes are least important metric [11:23:41] LM: back to point about encouraging docs to be revised [11:23:55] LM: there are docs that have not been revised but need to [11:24:39] Keith: decouple decision to revise document from decision regarding what is the intended level [11:24:56] Scott B: depends on the scope of changes [11:25:08] David B: Proposal 1 [11:25:27] no signficant change to 2026 [11:25:46] but make current system work better [11:25:56] general operational improvements [11:26:00] Proposal 2 [11:26:19] confirm 2026 intention but implement strict procedures to make it really work this time [11:26:34] Proposal 3 [11:26:35] I kind of like proposal 2 even though it's not at all what I would have suggested! [11:26:42] prune the process [11:27:05] prune number of standards levels to two (Draft Standard and Internet Standard) [11:27:12] Proposal 4: slash and burn [11:27:23] one standard level [11:27:39] (same threshold as Proposed Standard today) [11:28:11] Proposal 5: declare victory [11:28:23] just revise 2026 to document current practice [11:28:35] Common Ideas.... [11:28:54] WG snapshots: declare doc as stable [11:29:08] IETF snapshots: stable WG drafts approved by ADs or IESG [11:29:18] Interop and deployment register? [11:29:31] explicit version number to track protocol versions [11:29:41] better process documentation and tracking [11:30:24] Brian C: connection here to document shepherding etc. [11:31:21] Aaron Falk: I get stuck on (1) what happens to WG and (2) what happens to current standards [11:31:33] AF: this could be disruptive [11:31:58] Keith: what kind of tracking of "good" vs "bad" documents [11:32:03] or good vs. not so good [11:32:40] e.g., is tracking internal or external? need to be reflected by something on the cover of the document [11:32:50] (internal to IETF) [11:33:37] Eliot: propose that we take "just revise 2026" off the table [11:33:58] John Klensin: defacto this means one standards level [11:34:58] DB: so you want to take proposal 2 off the table [11:35:04] room consensus: no! [11:35:41] Larry M: reality does match the written record, so first step is to tell the truth about where we are today [11:36:39] Paul Hoffman: what does the outside world think? [11:36:50] PH: if we do slash and burn, outside world would be happy [11:37:23] PH: concern in vendor world about how our process affects them whether or not they follow our process [11:37:47] Brian C: do you think they want version numbering so they know they are using TCP v7 or whatever? [11:37:50] PH: yes [11:38:13] ?? interop and deployment register would be most helpful [11:38:35] pros and cons [11:38:46] Endre Gr√∏tnes [11:38:53] thanks [11:39:06] going too fast for the scribe, refer to I-D [11:39:10] (known him for a long time...) [11:40:34] Kurt Zeilenga: I don't see much consistency in our current processes across WGs [11:40:54] Scott B: e.g., Routing Area has different criteria [11:41:24] Aaron Falk: snapshots may vary across WGs and areas as well [11:42:32] Keith: could we describe more clearly the interop and deployment registry? [11:43:04] John ?: I-D forthcoming on registry [11:43:34] Endre: differentiate pros and cons for internal IETF use and external consumption [11:43:48] Questions: any major options missing? [11:44:08] another option: do nothing [11:45:06] Harald: do nothing means we can stop having these discussions :-) [11:45:41] no - option 5 means we can stop having these discussions. do nothing means we continue having this discussion! [11:46:12] oh, I thought you mean this = discussions in this WG [11:46:19] are the descriptions reasonably accurate? [11:46:47] how do we refine the pros and cons? [11:47:46] Paul H: one refinement is "for whom are we doing this?" [11:49:20] Brian C: not sure we have a good handle on the pros and cons [11:50:08] John K: we need to understand the overlap between these proposals [11:51:14] psa: do we need to pursue a path of decomposition and recomposition? [11:51:57] Keith: we need to know whether we can make things like the interop/deployment registry work before we can determine if it will be a good thing [11:52:13] Spencer D: I would like to see what we can take off the table at this meeting [11:53:08] John K: cost/benefit tradeoffs is more objective than "goodness" [11:53:58] Larry M: interop currently not revisited after interop required for draft [11:54:49] Brian C: I would like to see discussion of pros and cons on the list [11:55:31] We could certainly oblige John... [11:55:56] John Klensin: "A Different Access and Maintenance Model for the Standards Track" [11:56:32] draft-klensin-newtrk-std-repurposing vs. draft-loughney-what-standards [11:56:44] first, some history [11:57:14] three series for standards track: RFC, STD, and BCP [11:57:21] but one set of documents [11:57:46] proposals for new documents: Loughney: new "label", web page with information [11:57:59] Klensin: real STD documents with definitions, commentary, history [12:00:05] a separate STD document would enable us to track what changes happened when, errata, etc. [12:00:52] John L is talking about labeling and web page descriptions, etc., whereas John K talks about changing the documentation model [12:02:19] Aaron: if we are terrible writing AS docs, why would be good at writing these new STD docs? [12:03:25] JK: the question is how we document clearly and publicly what the IETF was doing when, for example, it published RFC 2821 [12:04:25] Keith: trying to understand how this will help me [12:04:43] Keith: this might help with referencing something like TCP [12:04:56] Scott B: actually TCP is now a poster child for this problem [12:05:25] Keith: I'm more interested in things that are not yet standards, such as SIP [12:05:45] John K: something I did not mention is that a standard number goes on something the moment it goes to proposed [12:06:01] JK: this doesn't require changing the standards process [12:06:34] JK: 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" [12:06:50] Bob Braden: we're working towards creating a new namespace for standards [12:07:12] BB: RFCs are in part document labels, but not standards lavels [12:07:14] labels [12:07:28] agreement that that is the fundamental issue [12:07:53] JK: attempt to separate documents registry issue from the standards issue [12:08:39] JK: two issues: (1) standards namespace (2) boundaries of labels [12:08:57] Aaron Falk: connection here with proto team [12:09:12] AF: trying to get WG chairs to write protocol piece of action statement [12:10:05] JK: this brings protocol action statements closer to WGs, which have the most local knowledge [12:10:14] JK: the proto team effort is probably an important component here [12:10:32] John Loughney: I think JK and I are attempting the same thing [12:10:53] JL: how much do we capture and how do we do it? [12:11:16] JL: e.g., never clear how updates and obsoletes work [12:11:39] Scottt B: making it clear *how* something updates or obsoletes [12:12:19] Larry M: such an overall document needs to specify what is missing and what is there [12:12:53] JK: yes, such as informational drafts, mailing list discussions, and things that have never been written down (the "oral tradition"?) [12:13:17] Larry M: some examples might be helpful [12:13:52] Keith: what direction are we really heading for in terms of document type? [12:14:09] bibliography, document tree, a full profile? [12:15:18] JK: this would become part of the process by which a protocol action happens [12:15:48] right now RFC Editor asks author if alleged error is an error, if so posted to Errata Sheet [12:16:00] but no process or authenticity to such statements [12:16:56] JK: so this proposal replaces that kind of process [12:17:11] adding IESG discretion and so on (yet to be worked out) [12:20:20] Scott B: 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 [12:21:00] Bob Braden: errata on standards are really standards issues [12:21:12] BB: and the RFC Editor now refers those to the IESG [12:22:02] Aaron Falk: don't we need to version the STD docs? [12:22:34] JK/SB: conformance with STD doc as of this date [12:23:17] Eliot Lear: I like the idea, though I think it needs to be less verbose [12:23:59] JK: references to peripheral URIs etc. would be dangerous [12:24:52] Larry M: change RFC so that it contains pointer to the document that describes the STD [12:25:36] JK: RFC is a document register, here we are talking about a STD register [12:26:25] Bob Braden: would be useful to separate engineering of new namespace from process [12:26:43] I love that SIP has become the canonical example for this kind of thing. [12:26:47] heh [12:27:07] It *used* to be HTTP! [12:27:21] s/SIP/TCP/ would be just as good [12:27:43] Scott B: you said STD 35 vs. "SIP" [12:28:13] Scott B: frequently our standards are known by a colloquial name [12:29:24] John L: good to break out some of the pieces, make one of these STD documents as an I-D [12:29:40] JK: maintenance models [12:29:44] (next slide) [12:29:58] Today: RFC Editor "errata sheets" (not authoritative) [12:30:21] update process involves full document replacement, with low-info obsoletes or replaces tagging [12:30:28] Proposed.... [12:30:56] Klensin: documents which are easy for the IESG to change, text descriptions of relationships, impl status, etc. [12:31:17] Loughney: introduce maintenance teams and experts, etc. [12:31:37] JK: personal opinion is that proposals address same general space and main ideas are compatible [12:32:15] repurposing STDs does not change basic way in which we work, only how things are documented -- may speed things up without more risk [12:33:01] 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 [12:33:41] JL: no matter what we do, someone needs to do it [12:33:55] JL: pointing to a document rather than a web page is fine with me [12:34:15] Scott B: two categories: (1) standards (2) historic [12:35:32] JK: we have a definition of what constitutes TCP etc. -- go through current STD index [12:37:05] Keith: if these are to be usable, these must carry a level of authority -- same or greater than the STD document [12:38:25] Yeah, WebDAV book took me three years, and people who want to implement WebDAV ask the WG to do that work for free. [12:38:38] lisa: exactly [12:38:51] lisa: your book came first to mind :-) [12:39:19] E.g. particularly, asking the WG to tell him how the Microsoft WebDAV implementation works, exactly! [12:39:20] * psa misses Larry's question [12:40:22] Bob Braden: nomenclature: mistake to call new this STD, perhaps ISN (Internet Standard Number) [12:40:56] BB: problem of social engineering: future standards-track documents must refer to ISN rather than RFC number [12:41:37] Kurt Z: you're assuming that future revision of standard is compatible with earlier version [12:42:26] Scott B: "this document as of this date" [12:43:40] Scott Lawrence: the need for non-normative references within standards [12:43:56] JK: this is in the I-D [12:44:06] Kert Z: [12:44:09] yow [12:45:00] Scott B: this is not entirely what applicability statements are defined as (e.g., not who should use this) [12:45:57] Scott B: should defining some level of indirection in standards be pursued in this working group? [12:46:14] Kurt Z: this seems orthogonal to defining what the standards track should be [12:46:38] JK: you are right, but that does not imply it is not good to separate that work [12:47:40] SB: if we have something like this which points to a set of documents, then the important of the levels is reduced [12:48:58] JK: 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. [12:50:08] John L: I agree that this work should be done here [12:50:37] Spencer: +1 [12:50:54] Scott B: hum: should work of this ilk be done in the WG [12:50:59] no hums against [12:51:43] lisa: I could do one for XMPP :-) [12:51:55] sure [12:52:05] go for it [12:52:27] Eliot Lear: "Let's Talk Old and Crufty" (next presentation) [12:53:18] STD 25, 26: Daytime, Time [12:53:26] STD 40: Host Access Protocol [12:53:33] STD 44: Hello [12:53:44] STD 47: SLIP [12:53:59] STD 52: IP over SMDS [12:54:16] These are all full standards! [12:54:30] more examples..... [12:54:42] BOOTP is a Draft Standard [12:55:28] Proposed Standards: TACACS use identification Telnet Option, ICMP Router Discovery, etc. [12:56:05] how about RFC 2748: COPS? [12:56:14] (poorly specified) [12:57:34] we might want to revisit some of these standards [12:57:41] criteria: [12:57:53] is the standard still used? if no, old and crufty [12:58:34] is the standard safe to use? [12:59:02] if no, maybe RFC required to describe the dangers [12:59:29] if it is safe, do we need an RFC to describe why it is old and crufty [12:59:42] John L: it's much harder to remove things that are dangerous [13:00:53] John K: this is exactly why the previous discussion needs to happen here [13:01:38] David B: difference between "waste of time" and "hazardous to your health" [13:01:48] who determines what is old and crufty? [13:02:15] committee, WG, individuals with approval of IESG? [13:03:30] draft-alvestrand-newtrk-historical-00 [13:04:39] Larry M: these docs can be short and are not that hard to do [13:05:25] Consideration of Really Useless Files Team [13:05:45] xmlscott: good work [13:06:15] Bob Braden: Jon Postel's opinion was that standards are forever, but personally I think that was the product of simpler times [13:06:37] BB: the older documents were grandfathered into standards before the IAB invented the standards process [13:06:46] (no process at that time) [13:07:52] Eliot: Historic has taken on connotation of "dangerous" but some of these are not dangerous, just old and no longer in (wide) use [13:08:23] Eliot: why do this at all? [13:09:09] 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 [13:09:25] Eliot: let deployment experience dictate lifetime of a standard [13:09:35] this discussion applies to standards-track document only [13:10:36] Keith: we might think it's dangerous, but someone might be using it in a restricted sense [13:10:58] SB: their use might not be as restricted as they think if it is going over IP [13:11:19] Eliot: the main benefit is to introduce a release valve [13:11:52] Kurt Z: perhaps more helpful to move things to Informational [13:13:09] John K: we have a relatively small number of things that have sat at PS or DS for a long time, whether we like them or not but the marketplace has accepted them [13:13:41] JK: do we advance them without applying all the more recent rules for document advancement? [13:15:19] Scott Lawrence: time is not as important as having an orderly process to address these matters [13:16:11] Eliot: only reason for time perspective is that we can remove the notion that proposed standards live forever [13:17:10] David P: 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 [13:17:44] Harald: we tried to define the most lightweight process possible to do this job [13:18:15] Eliot: Harald and I would like to do this [13:18:57] Eliot: and any change to Historic would happen only after IETF Last Call and IESG approval [13:19:29] Keith: concern that these standards are still being used [13:20:26] Eliot: document why thought to be old and crufty, put through IETF Last Call, if possible incorporate dissenting opinion [13:20:55] Scott B: hum: should Eliot Lear if think good idea to pursue? [13:21:06] two or three hums against, many for [13:22:00] hum if in favor of automatic advancement? [13:22:05] inconclusive [13:22:21] Harald: object to "automatic advancement" [13:23:31] will take it to the list [13:23:34] full log at: http://www.xmpp.org/ietf-logs/newtrk@ietf.xmpp.org/2004-08-05.html