Subject: [newtrk] Adding more step prior to Last Call

From: John C Klensin <[email-masked]>
Date: Sat, 23 Oct 2004 12:22:53 -0400

I decided this really needed to be a separate thread...

There are several proposals around that would impose additional
requirements or steps on document processing between the time a
WG concludes that it is finished with them technically and the
time a Last Call is issued (or permitted to conclude so that the
IESG can actually process a document).   Some of those steps are
almost trivial, some are clearly significant, and others are
debatable as to impact.   The proposals, some of which have not
really been documented, include...

	(1) Pekka's suggestion for an IPR review and explicit
	pointer in the last call announcement (see note posted
	to the list a few minutes ago)
	
	(2) The implied requirement of
	"draft-ietf-newtrk-isd-repurposing" that a decision be
	made as to whether the proposed document is part of an
	existing standard or should be considered stand-alone.
	
	(3) The other implied requirement of that document that
	"obsoletes: foo" or "updates: bar" be supplemented with
	real text that describes what was done and, when
	appropriate, why.
	
	(4) The requirement for IANA signoff on any actions they
	are expected to take when the document is approved (this
	requirement is already part of our procedures, but,
	apparently, the IESG has sometimes not waited for
	explicit signoff before approving a document).
	
	(5) The periodic suggestions that documents should go
	through a editorial review, or even a professional
	editing pass, prior to Last Call so that the community
	can look at a document that is as clear as possible and
	be more assured that what the IESG approves and what is
	ultimately published will represent the same
	specification.

There are probably others.  

I suggest that it would be useful to have a discussion, either
on this list or in Washington, about whether the community is
willing to tolerate any additional delays in getting documents
out for Last Call or from the nominal end of Last Call to IESG
processing.  I note that several of the things that appear to be
very large above may be just instances of "delay now or delay
later".  For example, if the RFC Editor won't publish before
IANA signs off, it may make no difference to time-to-publication
whether the IANA holds up the last call or holds up publication.
Similarly, the editing implied by the last statement may need to
be done sooner or later so, for document that will be approved,
doing it before last call just shortens the time between IESG
approval and publication. (However, if editing resources are put
into documents that are ultimately completely rejected, those
resources are wasted.)

    john

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Oct 2004 16:15:28 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "John" == John C Klensin <[email-masked]> writes:
    John> I suggest that it would be useful to have a discussion, either
    John> on this list or in Washington, about whether the community is
    John> willing to tolerate any additional delays in getting documents
    John> out for Last Call or from the nominal end of Last Call to IESG
    John> processing.  I note that several of the things that appear to

  My answer is no.   The process is already too long.

  I expect, when I see an ID going through multiple revisions and being
discussed, that it is still open for technical changes. 
  Significant flaws can still be fixed, and the excuse of "existing
code" can not be raised. (I've encountered multiple places where
poor choices in on-the-wire encoding leads to trivial buffer-overflow
vulnerabilities)

  What I experience is that an ID gets to a particular place, and
without a clear statement or *technical* review (a public decision),
becomes finished from a technical point of view. 
  Code is written, and any changes are now considered a problem.
  The document has moved, as far as I'm concerned, in effect, from "ID"
to informal PS.

    John> later".  For example, if the RFC Editor won't publish before
    John> IANA signs off, it may make no difference to time-to-publication
    John> whether the IANA holds up the last call or holds up
    John> publication.

  Unless we significant reduce the number of hurdles to get to PS, I
think that it should be possible to get IANA assigned numbers long
before the document enters the long process of last calls, etc. 

    John> Similarly, the editing implied by the last statement may need to
    John> be done sooner or later so, for document that will be approved,
    John> doing it before last call just shortens the time between IESG
    John> approval and publication. (However, if editing resources are put
    John> into documents that are ultimately completely rejected, those
    John> resources are wasted.)

  If we want to reduce editing effort, then we probably need to have
ID writing training sessions, akin to chair training sessions.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 23 Oct 2004 16:36:11 -0400

>ID writing training sessions, akin to chair training sessions.

Just FYI -- We have had editors training sessions on Sunday 
afternoons during the last couple of IETF meetings, and we will have 
one on Sunday afternoon in D.C.  All are welcome to attend!

Margaret
(Wearing her EDU Team Leader hat)
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Larry Masinter <[email-masked]>
Date: Sat, 23 Oct 2004 20:10:19 -0700

Almost all of these are actually the responsibility of
the editors of the document, before the document reaches
working group last call, much less IETF last call. 

> IESG can actually process a document).  

I think almost all of these are the responsibility of
the editors of the document, before it even reaches
working group last call, so I don't think it's necessarily
adding additional steps "between the time a WG concludes"
and "the time the Last Call is permitted to conclude".

> 	to the list a few minutes ago)

The chairs should ensure this is part of any WG last call.
The IPR information should be kept online for every working
group draft, so that this is just some standard boilerplate
in a working group last call message, pointing to the IPR
information linked to the WG charter page or to a page
whose name can be derived from the ID name.

> 	existing standard or should be considered stand-alone.

This belongs in the Advice to RFC Authors, that the document
should say what standard it is intended to be part of. This
should be part of the WG last call review.
	
> 	real text that describes what was done and, when

Most documents I've worked on do this, so this
just needs to be part of the standard advice to RFC authors
and chair responsibility during WG last call.
	
> 	explicit signoff before approving a document).

Well, apparently the ADs wait for IANA review. IANA seems
to be working to give earlier advice (table at IETF meetings),
so perhaps we could get IANA earlier review, for those documents
that need them.

> 	ultimately published will represent the same

The chairs are responsible for selecting document editors,
and if the document authors need editing help, the chairs should
try to obtain it. This should be a chair responsibility early
in the process.

> processing.

We should work hard to avoid making any of these 'post-processing
steps' and handle them before they even get to working group
last call.

Larry

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 23 Oct 2004 22:36:09 -0500

> one on Sunday afternoon in D.C.  All are welcome to attend!

And, just to send my first positive e-mail on the IETF this week, Avri 
Doria has done a really good job of assembling this training and 
delivering it - if you can't wait until DC, it's available at 
http://edu.ietf.org/, along with a number of other training slide 
decks - and the RFC Editor has been present in the room to answer 
questions every time it's been offered so far.

And you can stick around for the chair training session that follows 
immediately, and then you'll know everything we've been able to find 
written down on how to drag an ID through the publication process...

Spencer 

.

---

From: John C Klensin <[email-masked]>
Date: Sat, 23 Oct 2004 20:37:03 -0400

--On Saturday, October 23, 2004 4:36 PM -0400 Margaret Wasserman 
<[email-masked]> wrote:

>>   If we want to reduce editing effort, then we probably need
>>   to have ID writing training sessions, akin to chair
>> training sessions.
>
> afternoons during the last couple of IETF meetings, and we
> will have one on Sunday afternoon in D.C.  All are welcome to
> attend!

Margaret,

I don't have a clear sense any more about what "typical" 
documents the IESG or RFC Editor sees, but my sense is that the 
core editing and comprehensibility problems are due to:

    (i) I-Ds are often written in a conversational tone,
    pointing out issues to relevant WGs and others, rather than
    in the more formal tone of a would-be standard.  There isn't
    a clear place in the process to edit one into the other, so
    sometimes these relatively informal pieces hit the RFC
    Editor and then need considerable work.

    (ii) English is not an easy language for non-native speakers
    to write well, and we have ample evidence that many native
    speakers find it difficult as well.

You will forgive me if I am not optimistic about a few hours of 
"editor training session" curing either of those problems.

      john

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 24 Oct 2004 14:56:01 -0500

John,

Very reasonable concerns.

My posting will be the one that slides this thread over the edge to 
"off-topic", but, to try to phrase this in NEWTRK terms,

- We still see document editors and working group chairs telling us 
that they learned something from attending the Sunday afternoon 
classes, so I believe these classes qualify as "draining the swamp" 
activities, even if they don't ensure world peace, cure cancer, or 
ensure that all drafts are accurate and readable (yes, some swamp 
water remains in the swamp).

- The EDU team (and others) have discussed holding technical writer 
training, which would have the side effect of increased awareness that 
Internet Drafts are not just long mailing list postings with 3667/3668 
notifications. One point of view is that many IETF participants likely 
have access to very reasonable training on technical writing through 
sponsor organizations, so we are hoping to focus IETF training in 
areas where this isn't the case (conversely, if we don't offer IETF WG 
chair training, no one else will, either).

- The EDU team (and others) have discussed the "English as a Second 
Language" situation a few times, and we're not sure how any class 
addressing this issue would scale. In Seoul, Changhoon Kim gave the 
first non-English IETF Newcomer's training, and the room was PACKED - 
I estimated over 300 participants - so there's at least SOME 
opportunity for us to talk about what "English" means with some ESL 
participants, but we don't know how to do this if we're not meeting at 
a non-English-host venue. We could hold training in French next 
summer, but I don't know when we would be able to hold training in 
other languages... this isn't quite what John is talking about, but 
figuring out how to do Newcomer's training is actually easier than 
figuring out how to do English-language technical writing training for 
ESL participants, and even this isn't easy.

All in all, the best we've been able to come up with is "stress in 
both the editors training and WG chairs training that authors/editors 
are expected to come up with drafts written in clear English (whether 
the challenge is ESL, poor native-English writing skills, or just 
mental confusion), and WG chairs are empowered to solicit reviews, add 
editors or even replace editors to ensure this happens". Other 
suggestions are solicited, of course!

Spencer
>
> Margaret,
>
> I don't have a clear sense any more about what "typical" documents 
> the IESG or RFC Editor sees, but my sense is that the core editing 
> and comprehensibility problems are due to:
>

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 25 Oct 2004 08:57:10 +0200

> ID writing training sessions, akin to chair training sessions.

This is a good idea on its own merits.
The EDU team has run those at the last 2(?) IETFs.
Look for "editor training" in the agenda.

.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Oct 2004 09:06:06 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Harald" == Harald Tveit Alvestrand <[email-masked]> writes:
    >> If we want to reduce editing effort, then we probably need to
    >> have ID writing training sessions, akin to chair training
    >> sessions.

    Harald> This is a good idea on its own merits.  The EDU team has run
    Harald> those at the last 2(?) IETFs.  Look for "editor training" in
    Harald> the agenda.

  Margaret, is the material available?
  The next suggestion I have is to have some kind of coaching/mentoring
system. Like "Pay it forward", if you get coached, you gotta volunteer
to help someone else.

- --

.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Oct 2004 09:04:08 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    Margaret> Just FYI -- We have had editors training sessions on
    Margaret> Sunday afternoons during the last couple of IETF meetings,
    Margaret> and we will have one on Sunday afternoon in D.C.  All are
    Margaret> welcome to attend!

  Having missed the last IETF, I didn't know.
  I would attend this time, but I won't arrive on Sunday until late.

- --

.