[10:00:08] --- psavola has joined
[10:52:38] --- PaulHoffman has joined
[10:52:57] <PaulHoffman> And who is PSA?
[10:53:20] <PaulHoffman> Or am I the only one here?
[10:55:53] --- jschoenwae@jabber.org has joined
[10:57:39] <PaulHoffman> I'm not hearing anything on the audio feed...
[10:58:12] <PaulHoffman> G'morning Pekka
[11:00:46] --- bert has joined
[11:01:06] --- resnick has joined
[11:01:09] <bert> meeting still has to start
[11:01:26] <PaulHoffman> OK. Still nothing on the audio.
[11:04:46] <PaulHoffman> Anyone/
[11:05:15] --- becarpenter has joined
[11:05:34] <becarpenter> Any audio now?
[11:05:45] --- falk has joined
[11:05:46] <PaulHoffman> Yes, but very very quietly.
[11:06:00] <becarpenter> We're using the mikes
[11:06:03] <psavola> psa is probably mr saint-andre or whoever from jabber.org
[11:06:41] <PaulHoffman> I'll survive. But thanks!
[11:06:43] --- lixia has joined
[11:06:44] --- Ed J. has joined
[11:06:53] <Ed J.> Agenda:
[11:06:58] <Ed J.> 0900 bash
[11:07:15] <Ed J.> 09h10 Update from Bert ...
[11:07:20] <Ed J.> Intro what is this?
[11:07:41] <Ed J.> ... review of req'ts for the process and structure of tech spec publications that is critical to the IETF's work
[11:08:07] <Ed J.> constructive enumerations and expressions of IETF public'n req'ts, withour predjudice as to whether the req'ts are currently met or not
[11:08:18] <Ed J.> This is NOT:
[11:08:31] --- dcrocker has joined
[11:08:36] <Ed J.> whether output is referrred to as RFCs or ISDs or what "is" and RFC
[11:09:04] <Ed J.> later: we'll have a separate discussion on how to map this to existing, modified, or new publication activities
[11:09:26] --- jimsch has joined
[11:10:01] <Ed J.> We need to decide what to do, before discussing the *right* format to do it in
[11:10:23] --- nm has joined
[11:10:25] <Ed J.> Bert about to start his presentation
[11:10:35] --- sconte has joined
[11:11:13] <Ed J.> Report on the early-copy-editinng experiment
[11:11:22] <Ed J.> ops.ietf.org/ece
[11:11:33] --- jschoenwae@jabber.org has left: Replaced by new connection
[11:11:39] <Ed J.> lists the docs that have gone thru the process up to now
[11:11:47] <Ed J.> will be kept up to date as we learn more later
[11:11:52] <Ed J.> Experiment initiators
[11:12:05] <Ed J.> Leslie, Allison, Bert, Aaron Joyce, Bob
[11:12:09] <Ed J.> Workers+
[11:12:20] <Ed J.> Alice Hagens - (FRC-Editor) - great job
[11:12:27] <Ed J.> Editors/WG-Chairs of these WGs
[11:12:30] <Ed J.> AAA
[11:12:32] <Ed J.> ADSLMIB
[11:12:35] <Ed J.> MoBIKE
[11:12:37] <Ed J.> SECSH
[11:12:39] <Ed J.> SIP
[11:12:42] <Ed J.> v6ops
[11:13:15] <Ed J.> We have not done all the areas yet which may be useful, but certainly a good mix
[11:13:24] <Ed J.> Objectives of the experiment were:
[11:13:33] <Ed J.> Can we improve document quality early in the process?
[11:13:41] <Ed J.> e.g. before WG last call
[11:13:43] --- Bill has joined
[11:14:08] <Ed J.> This was (and still is) a very, very, very limited experiment (only 6 documents)
[11:14:18] <Ed J.> to identify issues
[11:14:25] --- jimsch has left
[11:14:27] <Ed J.> Expected / hoped for impact:
[11:14:42] <Ed J.> positive impact on WG Last Call, AD review, IETF Last Call and IESG review
[11:14:57] <Ed J.> - less copy-editing, so faster process after IESG approval
[11:15:08] <dcrocker> "before wg last call" covers a wide range of time. Is there a label that would better describe a more precise period in the wg process? (the concept of snapshot was intended to get at this, I think.)
[11:15:13] <Ed J.> - reduction of time spent in status AUTH48
[11:15:14] --- lixia has left: Replaced by new connection
[11:16:02] <Ed J.> first hoped-for impact is expected because of clearer/better text early on
[11:16:35] <Ed J.> - second hoped-for result is due to reduction in time between IESG approval and RFC publication
[11:17:11] <Ed J.> - last one is expected because there should be less changes (if any) betweem the approved text and the rfc-to-be-published
[11:17:13] <Bill> I was assuming "immediately before"
[11:18:03] <Ed J.> What was done:
[11:18:14] <Ed J.> to make the experiment run well:
[11:18:25] --- ole has joined
[11:18:29] <Ed J.> 1) serialized the input from WGs into RFC-Editor via Bert
[11:18:48] <Ed J.> 2) Submit/edit .XML source files to/by the RFC-editor
[11:19:01] --- leslie@ecotroph.net has joined
[11:19:04] <Ed J.> 3) RFC-Editor returned .XML file via Bert
[11:19:23] <Ed J.> 4) Author checks/edits .XML and then regenerates I-D
[11:19:43] <leslie@ecotroph.net> The slides I have should now be up on the meeting materials page.
[11:19:49] --- klensin has joined
[11:19:50] <Ed J.> 5) That I-D (from #4) get WG Last Called (.XML file of that ID to Bert)
[11:20:06] <Ed J.> 6) Kept rack of timings (i.e. intervals) and number of changes
[11:20:09] <Ed J.> track
[11:20:38] <Ed J.> Bert's summary of data points is:
[11:20:51] <leslie@ecotroph.net> https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64
[11:21:04] <Ed J.> was 17 days for 6 docs = approx average of 3
[11:21:07] --- yjs has joined
[11:21:12] <Ed J.> HOURS SPENT by RFC-EDITOR
[11:21:40] <Ed J.> was 43 .... total of 354 pages = approx 1 hr per 8 or 9 pages
[11:21:49] <Ed J.> # OF CHANGES BY RFC-EDITOR
[11:21:54] <PaulHoffman> *thanks Leslie!*
[11:21:58] <Ed J.> was 1149 lines
[11:22:20] <Ed J.> was additional 1360 changes to documents
[11:22:42] <Ed J.> 311 of these were for future tense (RFC-editor suggested author use present tense instead)
[11:22:50] <Ed J.> 860 changes were by error
[11:23:09] <Ed J.> (e.g. RFC author admitted to accidentally submitting the wrong version)
[11:23:21] --- Melinda has joined
[11:23:21] <Ed J.> NUMBER OF CHANGES after WG LAST CALL:
[11:23:37] <Ed J.> - is still to be determined; not sure all LCs are ended
[11:23:46] --- yjs has left
[11:25:35] <Ed J.> Summary of Bert's perception:
[11:25:50] <Ed J.> 1) We skipped many source control steps
[11:25:59] <Ed J.> - pity. we may need an IETF service for that
[11:26:10] <Ed J.> 2) This was/is a positive experience
[11:26:15] <Ed J.> 3) Great turnaround
[11:26:25] <Ed J.> from the RFC editor
[11:26:44] <Ed J.> 4) Actual work to serialize all this was tough
[11:26:55] --- ole has left
[11:27:15] <Ed J.> perception is may not (cannot) channel / seriealize if we scale to a production environment
[11:27:16] --- weiler has joined
[11:27:29] <Ed J.> 5) Also need to be carefule what is shipped each way
[11:27:36] <Ed J.> 6) didn't catch last point
[11:27:48] <Ed J.> Bert's final slide = "Next steps"
[11:28:05] <Ed J.> - follow-up on what happens with docs that participated in this experiment
[11:28:16] <Ed J.> - do more experiments
[11:28:22] <Ed J.> - to get more data points (6 is not enough)
[11:28:35] <Ed J.> - choose to include other source formats
[11:28:44] <Ed J.> - use a commodity copy-editor
[11:29:09] <Ed J.> Aaron Falk at the MIC:
[11:30:47] <leslie@ecotroph.net> paul, re the audio -- are the people at the floor mic (e.g., aaron, right now) more audible than the speakers at the front (Bert just now)?
[11:30:50] <Ed J.> General process the RFC-Editor uses now is to draw on resources of commodity copy editors (as a magazine publisher would); these people are not familiar with the technical content of the IETF, but are very skilled at marking up editorial/proposed grammatical changes needed, which may help IETF-literate technical editors save time on their part of it
[11:31:07] <PaulHoffman> Leslie: Kinda.
[11:31:21] <PaulHoffman> Leslie: Aaron is always quiet anyway.
[11:32:28] <Ed J.> Aaron suggests what Bert called the early copy-edit experiment is actually done in two phases:
[11:32:52] --- david_partain has joined
[11:33:13] <Ed J.> step 1 is have input document marked-up by a copy editor, which they could do on hardcopy, or in softcopy
[11:33:32] <Ed J.> step 2 is to have the authors merge the suggested changes back into the source file
[11:33:50] <Ed J.> Paul - can you hear Leslie well now?
[11:34:27] <Melinda> It's so-so, but basically audible
[11:34:28] <PaulHoffman> Leslie: You were quiet on both. :-)
[11:34:37] <PaulHoffman> Agree with Melinda.
[11:34:58] <Ed J.> Pete Resnick at the MIC: As far as using commodity copy editors ... did I hear you say those folks are not technical, so they may suggest more changes than Alice would have?
[11:35:07] <Ed J.> Aaron: "Maybe"
[11:35:09] <leslie@ecotroph.net> OK. Sorry, looks like there's not much we can do about the audio. The question we were testing was whether the table mic and mobile mic were any different.
[11:35:43] --- jschoenwae@jabber.org has joined
[11:35:45] <Ed J.> Professional copy editors often try to suggest/enforce stylistic changes ...
[11:35:54] <Ed J.> which RFC-Editor does not do
[11:36:48] <Ed J.> one interesting case (recently) was a copy editor who suggested the word "consensus" be replaced by "agreement" in documents.
[11:36:48] --- lixia has joined
[11:36:55] <Ed J.> This was *not* a good suggestion
[11:36:59] <Ed J.> -------
[11:37:13] <Ed J.> New presentation by Alice Hagens (from RFC-Editor)
[11:37:19] <Bill> One copy editor I experienced had a policy of never using "etc.", and always replacing it with "and so on" - so it came back from copy editing talking about the /and so on/passwd file
[11:37:24] <Ed J.> She worked on experiment docs
[11:37:32] <Ed J.> Her process / tasks were
[11:37:34] <weiler> (I need to leave the physical room but will be attempting to follow the streaming feed, also)
[11:37:40] <Ed J.> read through and mark up input docs
[11:37:45] <Ed J.> - about 7 more things
[11:38:14] <falk> I sent a note on the soft audio to multicast@lists.uoregon.edu....
[11:38:22] <Ed J.> - now she is presenting a 7 x 7 table which i am not even going to try to enter here
[11:38:31] <Ed J.> :'-(
[11:38:32] <Bill> I was listening before I got here and i thought it was fine
[11:38:32] <falk> If someone has Joels' jabber you might ping him
[11:38:49] <Bill> The presentation is http://onsite.ietf.org/proceedings/05nov/slides/techspec-1.ppt
[11:39:09] <Melinda> The problem seems to be miking. This is *terrific* compared to what I was [not] hearing in some of the sessions yesterday - the archive is going to consist of hours of dead air.
[11:39:26] <Ed J.> SECSH document had 18 pages, took 2 hours, with few suggested changes, and 0 'notes to the author
[11:39:52] <Ed J.> AAA doc was 79 pages, took 14 hours (average 5.6 pages per hour), but lots of suggested changes
[11:39:54] <Bill> the room is hotter than the multicast, I guess, since Alice is almost overdriving the room system
[11:40:09] <Ed J.> and 3 notes in xml and 3 in e-mail to the Author
[11:40:58] <Ed J.> SIP document was 41 pages, took 8 hours to go thru (avg 5.1 apges/hr); again lots of changes, and 11 notes to the author in xml
[11:41:01] <PaulHoffman> Paul asks: why is this done in the early-editing experiment?
[11:41:10] <Ed J.> new slide: remaining Measurements
[11:41:16] <leslie@ecotroph.net> Paul -- what "this"?
[11:41:23] <PaulHoffman> "This" being formatting for RFC properness.
[11:41:24] <falk> Paul: why is 'what'?
[11:41:24] <Ed J.> - Time and changes when doc enters the queue
[11:41:50] <Ed J.> issues not resolved in exchnanges with authors/editors during early copy/edit phase
[11:42:01] <Ed J.> ----------------
[11:42:24] <Ed J.> New presentation by Miguel Garcia - "Early Copy-Edit Experiement"
[11:42:34] <Bill> This presentation: http://onsite.ietf.org/proceedings/05nov/slides/techspec-2.ppt
[11:42:46] <Ed J.> 80 page document (v-08) was published on Sept 21
[11:42:52] <leslie@ecotroph.net> Paul -- this was the "early editing"; in the ideal world, no further changes would have to be made
[11:43:02] <Ed J.> Submitted to RFC-editor 2 days later
[11:43:28] <Ed J.> Received RFC-editor comments back on Sept 28th (with 300 proposed changes)
[11:43:53] <falk> Paul: we don't do final formatting during the experiment. but this was an opportunity for an editor very familliar with the formatting to use XML2RFC and as a result she had a bunch of comments on how the formatting works. This feedback has generally been considered useful.
[11:43:53] <Ed J.> - one suggestion was to go a global change from future tense to present tense for readability
[11:44:18] <Ed J.> The Author accepted all of the changes
[11:44:38] <Ed J.> Version -09 was published on the following day (i.e. Sept 29)
[11:45:14] <Ed J.> On October 3rd, the -09 version started 3rd WGLC
[11:45:39] <Ed J.> WGLC ended oct 17th
[11:46:01] <Ed J.> Published -10 on Oct 21st, with about 100 new changes, only a few of which were technical
[11:46:06] <PaulHoffman> Aaron: that was a question for the room. :-) But thanks.
[11:46:17] <falk> no prob. :)
[11:46:20] <Ed J.> Thoughts/Impressions:
[11:46:44] <Ed J.> All changes suggested by the RFC Editor were editorial in nature:
[11:46:51] <Ed J.> --- impact on the WGLC = 0
[11:47:28] <Ed J.> --- but this relieved the document editor and the AD from needing to verify the nature of the changes (because they were all editorial)
[11:47:58] <Ed J.> The positive aspect of the early-copy edit experiment was
[11:48:16] <Ed J.> - the ability to get back the document, and to do the changes in .xml
[11:48:34] <leslie@ecotroph.net> all slides are now available at the meeting materials page
[11:48:58] <Ed J.> Impact on the timescale?
[11:49:15] <Ed J.> --- No impact detected. we could have waited 3 or 4 more weeks
[11:49:45] <PaulHoffman> Leslie: thanks again. That's really helpful.
[11:49:57] <leslie@ecotroph.net> Glad to help!
[11:50:40] <PaulHoffman> Random thought: maybe do the copyediting while the doc is in the IESG queue. They can then see if there were any non-editorial changes, and it doesn't cause WG timing issues.
[11:51:25] <Ed J.> Elwyn Davies now going to share a few of his thoughts on the v6ops document experiment
[11:51:26] <becarpenter> Elwyn Davies, no slides
[11:51:27] <leslie@ecotroph.net> Elwyn Davies is giving his experience now
[11:52:02] <Ed J.> The document did not really meet the criteria for the experiment, because it had already gone through WGLC
[11:52:09] <Ed J.> but anyway ...
[11:52:25] <Ed J.> the document cycled back to Elwyn thru Alice in about 3 days
[11:53:27] <Ed J.> 3 exchanges between Elwyn and Alice were needed to get the document thru; most changes were editorial; two issues were highlighted that did need sorting out, which were NOT editorial
[11:54:07] --- hta has joined
[11:54:08] <Ed J.> In terms of timing, Elwyn says the impact on the timeline would have been minimal
[11:54:56] <Ed J.> Resulting document by the time it got to IETF last call would have been an improvement (more readable by the community)
[11:55:21] <Ed J.> Not sure if taking the copy editing out of the serialization before IESG is a good idea or not
[11:56:06] <PaulHoffman> Random thought: If the result of copyediting is mostly editorial, the copyediting could also be done during IETF last call.
[11:56:21] <leslie@ecotroph.net> paul -- the key is in "mostly"
[11:56:22] <Ed J.> Bert replies that moving from experiment to production will need some thinking about where to put it.
[11:56:47] <Ed J.> For the experiment, they had to put it somewhere in the process
[11:56:49] <PaulHoffman> Of course, but it is still valid in IETF last call because the WG can review the results of the IETF Last Call.
[11:57:13] <Ed J.> yes
[11:57:38] <PaulHoffman> Random thought: if copyediting is input to the WG, IETF Last Call is appropriate for that kind of comment.
[11:58:46] <Ed J.> Leslie: Yes, we got numbers from this experiment, but recall it was only a 6 document experiment
[11:59:07] <Ed J.> All of the pieces are still in play
[12:00:02] <leslie@ecotroph.net> it really should be taken as valuable for the subjective experience to inform our own decisions about process going forward
[12:00:43] <Ed J.> -----------
[12:00:54] <Ed J.> MOBIKE experience
[12:01:00] <Ed J.> - things went smoothly
[12:01:15] <Ed J.> - had to wait a bit in the queue (beacuse another doc was being worked)
[12:01:41] <Ed J.> - there was a big difference in amount of changes
[12:01:51] <Ed J.> - in our case, there were not a lot of changes
[12:01:53] --- resnick has left: Replaced by new connection
[12:02:06] <Ed J.> - so focus should be on docs that need a lot of changes?
[12:02:30] --- resnick has joined
[12:02:30] --- resnick has left
[12:02:49] --- resnick has joined
[12:03:05] <Ed J.> Bert says: it is difficult to judge which documents need a lot of changes - this is subjective
[12:03:28] <Ed J.> Elwyn says genart team are not copy editors
[12:03:46] <Ed J.> ... so they will not pronounce on what needs a lot of copy editing, and those which don't
[12:03:49] <PaulHoffman> Paul say: a copyeditor can skim a doc and do triage for "how much is needed" in 10 minutes.
[12:04:53] <Ed J.> Spencer Dawkins now sharing his experience from 60 or 70 docs in the past 2 years
[12:05:26] <Ed J.> - docs which are not written well, but have already passed WGLC ...
[12:05:40] <Ed J.> may be good candidates for continuation of this experiment
[12:06:03] <Ed J.> Another idea is *groups* of documents
[12:06:11] <Ed J.> "e.g. these 4 documents do not seem consistent"
[12:07:08] <Ed J.> and that is because some groups of documents do not get read (as a group) until very late in the process
[12:07:23] <Ed J.> ---------------------
[12:07:48] <becarpenter> Allison is just getting ready
[12:07:50] <Ed J.> Allison now getting ready to speak
[12:08:01] <falk> PaulHoffman: how's the audio? I'm corresponding with Joel in mcast central. You might drop him an email at multicast@lists.uoregon.edu.
[12:08:07] --- ThOr101 has joined
[12:08:15] <leslie@ecotroph.net> for some strange reason, she doesn't want people to be able to IM her in presentation
[12:08:18] --- david_partain has left
[12:08:44] <Ed J.> All of the presentations are now available in the "meeting materials"
[12:08:47] <becarpenter> http://onsite.ietf.org/proceedings/05nov/slides/techspec-4.ppt coming up
[12:08:48] <PaulHoffman> I sent him mail almost an hour ago. It is still very quiet, but it is working when I have the volume on my Mac *and* the powered speakers cranked all the way up.
[12:09:17] <Ed J.> "A tech spec requirements draft" - mankin@psg.com
[12:10:08] <PaulHoffman> *raises hand.*
[12:10:24] <Ed J.> draft-mankin-pubreq-01.txt
[12:11:05] <Ed J.> about 20 people in the room have read the draft
[12:11:29] <Ed J.> Lifetime of a document:
[12:11:45] <Ed J.> Some time spent in WG
[12:11:52] <Ed J.> Some time in Pre-Approval
[12:12:03] <Ed J.> Eternity in Post-Approval
[12:12:12] <falk> Paul: all speakers or only some?
[12:12:19] <becarpenter> From audio central: he adjusted it some, but this room has a noisey audio cable, so raising the level raises the feedback
[12:12:31] <becarpenter> (he = Joel)
[12:12:37] <Ed J.> Where to put "users" = uncertain
[12:12:57] <PaulHoffman> The main speaker (Allison now) are OK. The other mics are really quiet
[12:13:03] <Ed J.> as in when do users "read" the document
[12:13:16] --- ThOr101 has left
[12:14:23] <Ed J.> Req-2: IETF documents move seamlessly from IETF tracking system into Tech Pub tracking system [not talk about how, but to we want this]
[12:14:49] <Ed J.> Req-3: IETF have as detailed visibility into Tech Pub tracking as into IETF tracking
[12:15:19] <Ed J.> Something that meets Req-3 is .... ? (this is a questsion from Aaron)
[12:15:42] <Ed J.> Answer: Correspondance between ADs and editor group
[12:15:47] <becarpenter> Q: what more detail is needed?
[12:16:57] <Ed J.> Comment from Aaron is Req-3 is vague (i.e. not specific enough)
[12:17:17] <Ed J.> Allison says the spirit of Req-3 is "transparency"
[12:17:38] <Ed J.> Have the mailing list author correspondance be public
[12:18:19] <Ed J.> Brian at the mic: We are trying hard to make all the details between IESG and author communications is captured in the I-D Tracker
[12:18:20] --- hta has left
[12:18:24] --- hta has joined
[12:18:39] <Ed J.> ... so it would be nice to have similar with RFC-Editor
[12:20:08] <Ed J.> Question (for the mailing list) may be "do we want Req-3" ?
[12:20:43] <Ed J.> Does the room/list feel that degree of tracking is important?
[12:21:34] <PaulHoffman> Paul says: We should be talking about what is said in the draft, not the very brief summary on the slides.
[12:22:46] <Ed J.> Bert says a qualifying "if" is needed, because if the time between IESG approval and RFC publication was zero, all of these requirements would be nice, but not essential
[12:22:55] <Ed J.> Leslie does not agree
[12:23:28] <Ed J.> This discussion is about all of the requirements of our technical publication process
[12:24:42] <Ed J.> Sense of room is Req-3 is in the right spirit, but needs more clarity in how it is worded
[12:25:38] <Ed J.> Does not seem to be any debate about the desirablility of Rea-2
[12:25:41] <PaulHoffman> *nods his head approvingly: do it in one system.*
[12:26:42] <Ed J.> New page: NON-AUTHOR EDITING
[12:27:13] <Ed J.> Pre-Req 7: Does the IETF shpherd/editor group appoint one person to coordinate the editor process?
[12:27:43] <Ed J.> Pre-req 8: How does the IETF handle non-author editing which affects consensus wording?
[12:27:51] <Bill> IMHO, one system is an instance of a seamless transfer, but if there are ways to do seamless transfers with multiple systems and there is some other reason to have multiple systems then that's sufficient
[12:30:08] <hta> and why is that the RFC Editor's business to set policy on? (comment on Bob Braden's comment)
[12:30:45] <PaulHoffman> *agrees with hta*
[12:31:38] <Ed J.> Pekka says it is useful to have some one responsible for the process
[12:31:42] <weiler> Any estimate of when we'll get to the next agenda item, "any other requirements"?
[12:31:52] <hta> 11:45?
[12:31:54] <Ed J.> but it is not sufficient that only one person is responsible for all the edits
[12:31:57] --- hartmans has joined
[12:32:07] <PaulHoffman> *agrees with hta*
[12:32:27] <leslie@ecotroph.net> I can curtail this disscussion
[12:32:41] <PaulHoffman> Leslie: you can try.
[12:32:42] <leslie@ecotroph.net> but my sense is that we need to do some consciousness raising here
[12:32:43] <hta> I think you should. the author policy is a *different* rathole.
[12:32:49] <leslie@ecotroph.net> Paul, you underestimate me
[12:32:50] <weiler> Just want an estimate of when to bail out of my other meeting and come back.
[12:32:50] <leslie@ecotroph.net> :-D
[12:33:41] --- ThOr101 has joined
[12:33:54] --- dcrocker has left: Disconnected
[12:33:54] <hta> for the jabber logs - Bob Braden's statement was that the RFC Editor requires signoff from all the authors in order to push back on dummy authors.....
[12:33:59] <Ed J.> Scott Bradner suggests each author or editor be the final entity to say "Yes, I agree with Foo getting published"
[12:35:04] <hta> (the copyright / signoff stuff is an argument in the other direction.... speaking as IPR temp-chair....)
[12:35:05] <Ed J.> Margaret suggests a complicating factor is we mix / confuse "credit" and "control"
[12:35:56] <Ed J.> If an author dies, and the WG continues and completes his/her draft, then that author deserves credit for the work that was done, but the deceased should not be the final control point
[12:36:06] <hartmans> I agree with the all authors sign off policy but think a lead author who has the token for making sure things happen is important.
[12:36:14] --- ThOr101 has left
[12:36:49] <hta> sam: that's a process shepherd - I think we've proved that we need the ability to check one.....
[12:37:26] <Ed J.> David Black likes Scott's suggestion, with one twist:
[12:38:07] <hartmans> I agree with I think David
[12:38:11] <Ed J.> empower the Shepherd to either exempt authors from having to respond (eg. because they don't participate in IETF anymore), or to remove ones who do not respond
[12:38:33] <Ed J.> More support for Margaret's suggestioon
[12:39:27] <Ed J.> Pre-req 8: How does the IETF handle non-author editing which affects consensus wording?
[12:40:39] <hta> 10 slides left, 50 minutes => 5 mins per slide removes the need to have any "any other business" on the agenda....
[12:40:42] <Ed J.> Leslie says: when non-author editing affects consensus wording, we need to decide what to do about it.
[12:41:11] * hta was burned by not managing to manage time in IPR yesterday...... still hurts...
[12:41:36] <Ed J.> Non-author changes in post-approval may be many; so are the author changes. Limitation would make the publication process more efficient.
[12:41:42] <becarpenter> hta: and would 2 hours have got us to yes?
[12:42:00] <leslie@ecotroph.net> I don't believe we need 30min to discuss "where from here".
[12:42:13] <leslie@ecotroph.net> That said, I do think we have time issues.
[12:42:15] <Ed J.> Req-9: Authors/IETF Editors must not initiate stylistic changes
[12:42:42] <hta> brian: the yes we got was OK. another hour (or limiting all presos to 2 slides each) would have gotten us a feeling that people had time to speak their mind - and might have gotten your comment in while people had a chance to digest & comment on it.
[12:43:03] <hta> on the "what should IETF grant rights to do" topic.
[12:43:19] <Ed J.> Rea-10: Any other small technical changes that have merit must be submited to the document shepherd within a short window of the document approval rather than at the time of publication. Large flaws may of course be identified any time.
[12:43:32] <leslie@ecotroph.net> I think we have 2 issues here:
[12:43:48] <leslie@ecotroph.net> 1/ people have been quiet on the mailing list (relatively), so it was hard to judge how much time things would take
[12:44:01] <leslie@ecotroph.net> 2/ we're getting a lot of socializing discussion about these, which takes time but mmay not be on topic
[12:44:17] <leslie@ecotroph.net> or, is on topic, but not in agenda.
[12:45:18] <PaulHoffman> The humorous thing about the socializing discussion is that the audio goes silent for 10 seconds every six minutes. This may be a predictor for me 30 years from now...
[12:45:30] <Ed J.> Margaret suggests that large flaws should be addressed by the WG that produced the (flawed) document
[12:46:27] <Ed J.> Allison suggests the Shepherd and WG Chair be responsible to assess the magnitude of the error, and steps to close the document ?
[12:46:50] <hartmans> I guess I disagree that you should have to withdraw publication for a show stopper.
[12:47:02] <hartmans> It seems if the fix is simple and can be agreed to quickly you should just be able to make the change.
[12:47:44] <hta> "withdraw publication" = "fix the bug", not "decide not to publish", I think?
[12:48:14] <falk> hta: possibly re-cycle through wglc and ietfLC?
[12:48:37] <PaulHoffman> Agree with Aaron. Start cycling again for any technical change.
[12:48:47] <Ed J.> Leslie is suggesting we will not get through a full discussion of Allison's document in the time remaining today ...
[12:48:50] <Ed J.> ... so ...
[12:49:18] <PaulHoffman> Just implemented that for a document of mine that was in the RFC Editor queue and was found to be insufficient by implementers.
[12:49:20] <Ed J.> now that quite of few of us have invested some time in thinking in this space this morning ...
[12:49:24] <Ed J.> Questions:
[12:49:29] <hartmans> hta: I understand. I just don't think you need to recycle all the time.
[12:49:34] <hartmans> It introduces significant delay.
[12:49:34] <Ed J.> 1) Should we charter a WG to do this?
[12:49:42] <Ed J.> 2) Discuss on the mailing list?
[12:49:55] <Ed J.> 3) Give Allison's document to a copy editor?
[12:50:00] <Ed J.> 4) Something else?
[12:50:21] <Ed J.> Assertion is there is a lot of work to be done here
[12:50:24] <weiler> there's a risk that the add'l requirements discussion will get shorted that way.....
[12:50:38] <PaulHoffman> *raises hand*
[12:50:53] <weiler> (agree with what?)
[12:50:59] <PaulHoffman> *raised hand for first choice*
[12:51:19] <hta> I didn't raise my hand for "willing to contribute"......
[12:51:44] <Ed J.> Discussion:
[12:52:14] <Ed J.> Document (in its current form) needs more work ...
[12:52:27] <Ed J.> ... and it may be premature to progress this to a WG now
[12:53:36] <Ed J.> The document identifies a collection of problems that are bothering us ... but using this document as the foundation for a way forward may be premature
[12:53:55] <Ed J.> Scott: I think there is a pony in or around here somewhere
[12:54:17] <Ed J.> The problem set exemplified by this document is a valuable thing to address
[12:54:20] <weiler> (the jabber version of that line must have lost some context)
[12:55:20] <Ed J.> Bert does want to work on this document
[12:56:00] <Ed J.> Bert: everything that gets done before IESG approval should cost the community less than fixes done later
[12:56:20] <hartmans> I think I disagree with Bert. RFC editor time is expensive, but wg participant time, WG chair time, AD time is expensive too.
[12:56:31] <weiler> re: Bert's comments on expense: having a tech editor fix grammar is far cheaper than having me (as an example) fix grammar. So I'm supportive of giving more help to editors early on.
[12:57:02] <resnick> The hourly rate of a good technical editor is still cheaper than my hourly rate.
[12:57:04] <hartmans> So, it is important to decide not to do things as soon as possible, but introducing ab bunch of control points or process hand offs to accomplish editing will just cost more money.
[12:57:11] <Ed J.> Margaret: If we do this in parallel with other things, i would support that
[12:57:11] <PaulHoffman> I also disagree with Bert.
[12:57:16] <hartmans> I don't think I disagree much with Bert's proposed implementation details.
[12:57:16] <PaulHoffman> I also agree with Pete.
[12:57:30] <Ed J.> Margarget: if the proposal is to do this first (before anything else), I would be against that
[12:57:35] <PaulHoffman> Copyeditors are happy to work for $50/hr in many places.
[12:59:44] <Ed J.> Brian C: We don't have text today, to put into an RFP (or SOW) in the near future for this function ... so if the community doesn't write it ...
[12:59:56] <Ed J.> someone else will have to
[13:00:50] <weiler> I didn't quite grok what Bob was saying -- could someone relay?
[13:01:29] <leslie@ecotroph.net> what I heard: the big problem is making better and more usable documents; everything else is noise, so this process (techspec) is putting effort in the wrong place
[13:01:32] <Ed J.> Allison: Within the current Statement of Work (SOW), as we do RFC publication, the IETF does it without a lot of consistency, document by document, WG by WG, Area by Area ...
[13:01:51] <Ed J.> "it" being technical publication ...
[13:02:06] <Ed J.> ... so agreeing on what we want (i.e. requirements) seems necessary
[13:02:37] <Ed J.> .. to guide IASA on decisions on what to pay for, how much to pay, etc.
[13:02:46] <Ed J.> ... so doing this thinking/specification in parallel with everything else is needed
[13:02:55] <weiler> Ed: thanks for doing this. It's very helpful.
[13:03:13] <Ed J.> Fingers are getting sore :-(
[13:04:01] <Ed J.> Bert: We need to define what our requirements are, to produce our documents.
[13:04:13] <Ed J.> Bert: unfortunately, we don't seem to be doing that today.
[13:04:30] <Ed J.> Bert: We seem to be talking about requirements to fix current process problems
[13:04:44] --- sconte has left
[13:04:46] <weiler> sounds like I need to show up again.
[13:04:54] <Ed J.> Bert: Let's think as if we had a clean slate.
[13:05:08] <Ed J.> Leslie: Yes, as a clean slate exercise - what are our requirements?
[13:05:23] <hta> sam, this is when you should come running!
[13:05:30] <Ed J.> Assertion is that material needs to be collected
[13:06:03] <Ed J.> newreq-1: A quick mechanism to fix bugs (e.g. errata process)
[13:06:03] <PaulHoffman> Paul says: Is it a requirement that we do English fixes on all documents, or only on "really bad" documents?
[13:08:58] <Ed J.> newreq-2: Make sure it is obvious that people who find a base document find and errata at the same time
[13:09:06] <Ed J.> any errate
[13:10:46] <Ed J.> newreq-3: The IETF needs a process to continue to use the individual submission path for ....
[13:10:59] <Ed J.> Still Harald is "worried"
[13:11:16] <Ed J.> Tech Pulication means getting documents out in a way they can be referenced, and quickly
[13:11:44] <Ed J.> a main point of "quickly" is knowing who to nudge to get something done quickly (so openess is needed)
[13:12:48] <Ed J.> Harald: Getting documents out and knowing what we submit for publication actually comes out is another part of the process which does not seem to be captured adequately
[13:13:09] <Ed J.> More about Errata:
[13:13:37] --- falk has left
[13:13:41] <PaulHoffman> I agree with Pasi. We would use the -bis process much more.
[13:13:49] <hta> he means that if it took 2 weeks we'd publish a new version, I think. He hasn't been part of the BGP update process in IDR.
[13:13:59] <PaulHoffman> Disagree with Allison: use -bis. The implementers want this.
[13:14:00] <Ed J.> Problems can be found in an RFC a year after publication, and we may not want to publish a new RFC in every case
[13:14:19] <leslie@ecotroph.net> and I doubt that, too -- unless we solve the "let's not re-open this document because of all the other questions we will revisit"
[13:14:26] <leslie@ecotroph.net> that will never be a 2 week process
[13:14:41] <Bill> right, reopening a document vs. "make a bitty change" is a social problem
[13:15:17] <Ed J.> Observation: The less editing you do, the more errata that will appear
[13:16:06] <Ed J.> There is an interesting person in Germany who reads every new RFC, and then sends a bug report (on most of them) directly to the authors
[13:17:04] <Ed J.> Any process other than "stop publishing RFCs" will produce some bugs
[13:17:37] <Ed J.> Final word from Leslie: Please do join the mailing list, so we can continue the discussion there.
[13:17:38] <PaulHoffman> Thank you Ed!
[13:17:41] <Ed J.> yw
[13:17:47] <Ed J.> Meeting ends ...
[13:18:01] --- Melinda has left
[13:18:02] --- hta has left
[13:18:13] --- klensin has left
[13:18:15] <PaulHoffman> /dashes out to feed the parking meter.
[13:19:05] --- nm has left
[13:19:13] --- resnick has left
[13:19:20] --- leslie@ecotroph.net has left: Logged out
[13:20:46] --- dcrocker has joined
[13:20:51] --- jschoenwae@jabber.org has left: Logged out
[13:21:12] --- Ed J. has left: Disconnected
[13:22:02] --- weiler has left
[13:24:00] --- Bill has left
[13:24:24] --- hartmans has left
[13:25:19] --- PaulHoffman has left
[13:27:40] --- lixia has left
[13:30:40] --- paulehoffman@jabber.org has joined
[13:31:06] <paulehoffman@jabber.org> If someone is still in the room, let EKR know he's on-mic.
[13:31:57] --- Bill has joined
[13:32:08] --- paulehoffman@jabber.org has left
[13:32:59] --- bert has left
[13:33:17] --- Bill has left
[13:38:02] --- becarpenter has left
[13:39:22] --- dcrocker has left
[13:53:36] --- becarpenter has joined
[13:57:19] --- psavola has left: Disconnected
[14:09:58] --- becarpenter has left
[15:03:06] --- falk has joined
[15:03:14] --- falk has left
[15:19:53] --- dcrocker has joined
[15:50:11] --- dcrocker has left
[19:56:07] --- jimsch has joined
[19:57:31] --- jimsch has left