Subject: [RTG-DIR] Document Mentors

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 31 Mar 2014 13:12:19 +0100

Hi,

One of the ideas to come out of the recent discussions is appointing a mentor
per document from the time it is adopted by a Routing Area working group until
it completes WG last call.

This would be voluntary in two dimensions:
- the WG chairs would need to deem that one would be beneficial
- we would have to find someone from the Directorate willing to
   take on the document.

We don't think that technology expertise is as useful in this as IETF clue and
general routing experience.

So, to take this forward we would need:
- WG chairs to say "Yes, we can see that that would have
   potential benefit
- Directorate members to say "Yes, we could take on that
  additional work.

Alia and I have put together some preliminary notes on how this would all hang
together.

Your opinions and rotten fruit are solicited.

Thanks,
Adrian and Alia

=========

Document Mentors in the Routing Area

The Problems: 

  a) Drafts get little review outside the working group and sometimes inside 
  the working group until after working group last call. At that point it is
often
  painful and costly to make meaningful improvements to the drafts.

  b) Authors may not know how or whom to ask for assistance  or review 
  (e.g., IANA section, Security Section, Operational and Management
  considerations, details of a protocol, etc. ).

The Goals:

  a) Excellent and consistent review at WG adoption and before WG last
  call.  

  b) Ability for prolonged discussion and problem-solving when the
  draft can still be easily enhanced.

  c) Reduced time to delivery of RFCs.

  d) Quality documents.

The Solution:

  A per-document mentor who is a known neutral party to whom the
  authors can go for advice on:
  - how to write a section
  - specific issues that arise
  - ways to resolve conflicts.

  The document mentor also watches the progress of the document
  and gives advice and steerage.

  It is not assumed that every document will need or benefit from 
  having a mentor.

The Expected Workload:

   The routing directorate has approximately 40 people.  If we assume
   that approximately 50 drafts pass WG adoption and a similar number
   pass WGLC each year, then the load is 2.5 documents per person
   per year.  If we assume that there are about 200 WG drafts in the
   Routing Area and that they all have mentors, then each Routing
   Directorate member will have 5 drafts that she or he is mentoring.

The Supporting Data Artefacts:

   a) As part of the Routing Area wiki, the areas of knowledge for
   each member of the Routing Directorate will be publicly specified.
   This is added to the wiki by the Routing Area Coordinators (or AD)
   when the member joins the Routing Directorate, updated by the
   member while he or she is on the Directorate, and updated by the
   Routing Area Coordinators (or AD) if and when the member's term
   renews.

   b) Document Mentor Availability and Assignments: As part of the
   Routing Area wiki, each Directorate member will specify the maximum
   number of documents that he or she is able to mentor.  Also listed
   will be the list of mentored documents (and a count).

        i) When a Directorate member is assigned as the Document
        mentor, the Routing Directorate Coordinator will update the
        wiki page and create a wiki page for the draft.

        ii) When a Document Mentor provides a review, that should be
        stored in the draft's wiki page along with the resolutions.

        iii) When the Document Mentor's final review at WGLC is done,
        the Document Mentor should move the draft to a list of
        "previously mentored documents" associated with their name.
        It is ideal to write up a summary of the document mentoring experience.

   c) Unmentored Documents: Drafts which have declined a document
   mentor should be listed on a wiki page.

   d) For each WG's wiki, it'd be useful to have the list of drafts
   with their associated Document Mentors (or lack thereof) and the
   link to the draft's wiki page.

The Basic Process:

  When a new WG draft is adopted, the WG chairs and the Routing
  Directorate Coordinators discuss and agree on possible Document
  Mentors (up to 3).  Then the Routing Directorate Coordinator
  confirms with the Routing Directorate members about their
  availability and willingness to mentor this particular draft. Once
  one is selected, the Routing Directorate Coordinator updates the
  wiki and notifies the WG chairs and draft authors.

     a) With the agreement of the ADs, a Document Mentor who is not a
     member of the Routing Directorate may be selected.

     b) The WG chairs can, after consulting with the draft authors,
     decline to have a Document Mentor.  

     c) The Document Mentor should coordinate with the Document
     Shepherd for hand-off after WGLC.

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 14:48:18 +0200

All,

Apologies, I used up all my expired produce in London about a week back, I have yet to stock up...

Sounds pretty reasonable to me - allowing as much, or as little, interference in document process as is necessary, and not stepping on the toes of current process steps. 

I would suspect, though, that the workload would be very heterogenous among documents, with some being "close to nothing" whereas others being "almost as much as the authors", and that "number of I-Ds mentored" is not a perfectly accurate way of distributing  the workload. Assuming that there's a sentient being (AD or RDC) somewhere in the process, that's probably not a problem.
 
There probably are edges to file off, but I say let's get to run the experiment and see what comes from it. 

I see that Adrian suggested two acceptable positive responses, depending on to which list one is subscribed, so count this as my:

	"Yes, we [I] could take on that additional work"

Cheers,

Thomas

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 31 Mar 2014 08:48:55 -0400

The only hole i see is your scale/workload numbers dont take into
consideration the fact that there could be a lot more spread than 200 active
documents per year that are in between WG adoption to publication.
And that at times that process takes a little longer.
Jari's tools could provide some stats (and i could be therefore off), but
to make my point  i will handwave and say it is a magnitude more docs,
some of which a mentor is responsible for and some which are making
progress.
This means each of the 40 people is actively mentoring about 25 documents
per year. And lets say 60 over 3 years. You will need a large number of people
in the directorate to scale.
And then there's handoff challenges. If i am mentoring a doc that is
not complete
before i let go ...

cheers,
jamal

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 15:12:58 +0200

Jamal,

> in the directorate to scale.

Scalability is an issue in whatever we are designing in the IETF, to be sure. But I think that various documents are very heterogenous in nature.

Some documents would be written by people who really do not need a mentor ("Come here, Ross Callon, so that this whippersnapper can tell you how the IETF works - and Adrian, now, let me explain to you what a good RFC looks like" -- that just doesn't seem plausible to happen).

Other documents would probably need the occasional review, but mostly be consensual and developed by a well engaged WG, so the "mentor" would be mostly redundant, and just "be there" without doing much.

A few documents would likely benefit from more continuing mentoring - unexperienced IETFers as authors, but eager to learn the ropes. That's actually the "good kind of effort" to spend, that's working on renewing the future stock of RTG-DIR members and WG Chairs. I know that when I put pen to paper for the first time in the IETF decades ago, I'd have appreciated having had a mentor.

Further, I predict that many documents would likely be rather bursty in the efforts required. If I was to mentor a document, I'd probably want to spend a good chunk of effort around WG adoption on reviews, discussions with the authors, commenting, learning what the WG wants with it - but, hopefully then it will drop to an occasional review (ideally, at least, looking at the diff at each release), discussions on precise points and potential pitfalls, and likely with another burst when the authors start preparing for WGLC.

I think that as long as the ADs are not mechanically dooling out documents, but there's a human in the loop to whom we can say "Well, gee, I may mentor just one document, but right now it's a full-time job to work with the authors, could you ask Jamal to take thisone instead?" we'll do alright.

> And then there's handoff challenges. If i am mentoring a doc that is

Worst case: think of the document taking over as "having just been called for WG adoption", so provide a review, chat with the authors. Best case, you have notes to hand over, or even sit down and have a beer with whoever takes over after you.

Anything more complicated than that?

Thomas

---

From: Acee Lindem <[email-masked]>
Date: Mon, 31 Mar 2014 13:40:05 +0000

Hi Thomas, Jamal, and Adrian, 
I agree with Jamal on scaling. There may not be an order of magnitude difference between the number of drafts accepted as WG documents and those that make it through WG last call but it is certainly some power of 2. Hence, we’d be increasing our workload by 2 to 4 times just in shear numbers without even taking into account the fact that the bad drafts will take much more time than the ones making it through WG last call. 
Thanks,
Acee

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 31 Mar 2014 09:50:54 -0400

Hi Thomas,

On Mon, Mar 31, 2014 at 9:12 AM, Thomas Clausen
<[email-masked]> wrote:

> Scalability is an issue in whatever we are designing in the IETF, to be sure.
> But I think that various documents are very heterogenous in nature.
>
> Some documents would be written by people who really do not need a mentor ("Come here, Ross >Callon, so that this whippersnapper can tell you how the IETF works - and Adrian, now, let me explain to >you what a good RFC looks like" -- that just doesn't seem plausible to happen).
>
> Other documents would probably need the occasional review, but mostly be consensual and developed >by a well engaged WG, so the "mentor" would be mostly redundant, and just "be there" without doing >much.
>
> A few documents would likely benefit from more continuing mentoring - unexperienced IETFers as >authors, but eager to learn the ropes. That's actually the "good kind of effort" to spend, that's working on >renewing the future stock of RTG-DIR members and WG Chairs.

You are right in that different docs will require different effort and
that on average the apocalypse
I am painting is exaggerated to make a point.
Again stats here would help. I think just a baseline response to "on
average how long
does it take to go from WG adoption to publication in the Routing
Area" would help
get an estimate. I have seen these stats on a per doc level - some
effort is needed to get
them on a per area aggregation. I think with such a stat at hand one
can deduce the average
time a mentor would have to be involved with a document.

>I know that when I put pen to paper for >the first time in the IETF decades ago, I'd have appreciated having had a mentor.
>

My view of mentorship is skewed a little. There has to be a return on
investment for the mentor.
If i am going to spend many hours reviewing and rewritting the draft,
I might as well be an author
and i have to be very interested in the topic iam volunteering for.
As an example, Linux has something called "kernel newbies" which is
supposed to be a mentorship interface
where experienced people come to help the newbies. In my opinion it is
a fringe group where people get
to learn but it rarely produces useful work that contributes to the
kernel proper. Not many experienced people
get involved at all (the choice is whether I am going to do more
exciting things or i have to handle newbie loops).
What helps some sanity in quality is the gatekeeper / maintainer of
the code - you send bad code that doesnt
conform, you are not going past the gate. And I think the current
system where you have Routing directorate
reviews serves that except they really have no authority (which is a
good thing).

> Anything more complicated than that?

Good ideas. We probably just need to revamp the routing area
directorate review involvement not to be
after the adoption but rather just before the shepherding step.

cheers,
jamal

---

From: "Russ White" <[email-masked]>
Date: Mon, 31 Mar 2014 10:15:34 -0400

> investment for the mentor.

This, IMHO, is the biggest blocker. While it "should be enough," to know
that we're improving the quality of the IETF's output, it's probably not.
Maybe add the mentor as "editor," or create a new "editor," type slot in the
acks, or something like that? 

:-)

Russ

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 16:18:11 +0200

Dear Jamal,

Below.

> time a mentor would have to be involved with a document.

The thing is, that averages not always are helpful. 

I have a document with the RFC Editor right now, where the -00 came out almost 10 years ago. From that -00, however, 4-6 other RFCs were shaken out over the years. To statistics, however, that document would look like a "10 year process" if seen in isolation. At the same time, I have a document sitting with the RFC Editor also, which hit the IESG in its -00 version. These may not be typical cases, but it's far from unheard of either, to see stuff of this sort.

I agree, though, that getting some data would be helpful. I am not sure, though, that we should hold up and wait for data before digging in. The data from the tracker is there to mine, in case we want to measure if there's any impact of this measure. 

More to the point...the tracker does not have any data on the "mentor workload incurred". Which is why I think that running what the ADs suggest as an experiment is a great idea. We can always kill it down the line  if it turns out to be a failure: not to help, to scale poorly, etc.

> and i have to be very interested in the topic iam volunteering for.

Fair enough.

Personally, I am grateful enough for the work that was done by others in building the Internet, and the help I got from elder IETFers when I started in the IETF, to want to "pay it forward" a bit, as best I can.

> reviews serves that except they really have no authority (which is a

That's a very different philosophy, I think. 

Essentially, you say that you prefer "spending time evaluating and rejecting a kernel-patch on submission" than "spending time making sure that submitted kernel-patches are good".

"Spending time evaluating and rejecting a kernel-patch on submission" is, essentially, that which we have now: IETF LCs with roadblocks by way of directorate reviews and ADs.

Speaking as an author, I'd think that getting "early guidance" is more valuable than getting "late roadblocks". Nothing more frustrating than a "late roadblock" when you feel you're done.

Speaking as a RTG-Dir member, I'd actually also much rather spend 1h30 mentoring someone early, than would I like to spend 1h writing a harsh review during IETF LC. I do personally believe that this is an "ounce of prevention worth a pound of cure" situation -- assuming that authors are working on more than a single document through their IETF careers.

> after the adoption but rather just before the shepherding step.

Well, I disagree there, I think at WG adoption is the right time. Just before shepherding step is (for all intents and purposes) the same as during IETF LC.

Thomas

---

From: Alia Atlas <[email-masked]>
Date: Mon, 31 Mar 2014 10:18:59 -0400

Acee,

Absolutely, this would be doing more work.  It would be doing it earlier in
the draft life-cycle when there is a chance of improving or killing bad
drafts that did make it past working group adoption.   Having better drafts
coming out out of WGLC seems to me to be a clear win - easier to
understand, better technology, common issues and nits addressed, faster to
process through the endgame (IETF Last Call, IESG, IANA, etc).

As for current scale, there are 187 WG drafts in routing plus 27 is IESG
processing.  At the moment, the routing directorate is not highly loaded.

Alia

On Mon, Mar 31, 2014 at 9:40 AM, Acee Lindem <[email-masked]>wrote:

> I agree with Jamal on scaling. There may not be an order of magnitude
> difference between the number of drafts accepted as WG documents and those
> that make it through WG last call but it is certainly some power of 2.
> Hence, we'd be increasing our workload by 2 to 4 times just in shear
> numbers without even taking into account the fact that the bad drafts will
> take much more time than the ones making it through WG last call.
> Thanks,
> Acee
>
>
> > Scalability is an issue in whatever we are designing in the IETF, to be
> sure. But I think that various documents are very heterogenous in nature.
> >
> > Some documents would be written by people who really do not need a
> mentor ("Come here, Ross Callon, so that this whippersnapper can tell you
> how the IETF works - and Adrian, now, let me explain to you what a good RFC
> looks like" -- that just doesn't seem plausible to happen).
> >
> > Other documents would probably need the occasional review, but mostly be
> consensual and developed by a well engaged WG, so the "mentor" would be
> mostly redundant, and just "be there" without doing much.
> >
> > A few documents would likely benefit from more continuing mentoring -
> unexperienced IETFers as authors, but eager to learn the ropes. That's
> actually the "good kind of effort" to spend, that's working on renewing the
> future stock of RTG-DIR members and WG Chairs. I know that when I put pen
> to paper for the first time in the IETF decades ago, I'd have appreciated
> having had a mentor.
> >
> > Further, I predict that many documents would likely be rather bursty in
> the efforts required. If I was to mentor a document, I'd probably want to
> spend a good chunk of effort around WG adoption on reviews, discussions
> with the authors, commenting, learning what the WG wants with it - but,
> hopefully then it will drop to an occasional review (ideally, at least,
> looking at the diff at each release), discussions on precise points and
> potential pitfalls, and likely with another burst when the authors start
> preparing for WGLC.
> >
> > I think that as long as the ADs are not mechanically dooling out
> documents, but there's a human in the loop to whom we can say "Well, gee, I
> may mentor just one document, but right now it's a full-time job to work
> with the authors, could you ask Jamal to take thisone instead?" we'll do
> alright.
> >
> > Worst case: think of the document taking over as "having just been
> called for WG adoption", so provide a review, chat with the authors. Best
> case, you have notes to hand over, or even sit down and have a beer with
> whoever takes over after you.
> >

---

From: Loa Andersson <[email-masked]>
Date: Mon, 31 Mar 2014 16:21:08 +0200

Acee, et.al.,

I did not read our ADs as "applicable to all documents", but a tool
to be used when beneficial.

Anyhow, I'm a bit concerned about the increasing number of rules that
pop up around documents. But so far I'll sit on my hands and hope that
it either turns out to be beneficial, or wither away because it is not.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 16:26:49 +0200

> acks, or something like that? 

Russ, often we do agree on things -- but in this case, Yikes..... ;)

1) Following the document authors development process is one thing. That could be the "RTG Dir document mentor".

2) Following the document authors through the review process (IETF LC, AD, IESG) is the job of the document shepherd.

3) Following the document through the RFC Editor process is the job of the authors (and perhaps the ADs, in case of non-editorial edits).

Sticking the "mentor" onto a document as an editor/co-author would also require the "mentor" to be part of 2) and 3) -- that seems to scale even less well :)

Also.....

Sticking the "mentor" onto a document as an editor/co-author is (imo) actually intellectually dishonest, and something I'd much ask to not have done to me, if I was a mentor of a doc. My contributions may be simply "process guidance" and I should not get any credit for the clever algorithm/protocol/design that somebody else came up with  (And, conversely, if by accident I was to come up with something clever, I'd want credit for that - not to share it with somebody just giving process advice).

And also, I may be assigned a document which I profoundly disagree with, or which my employer disagrees with, and having my name on it may be a bad career move.....

Thomas

---

From: "Russ White" <[email-masked]>
Date: Mon, 31 Mar 2014 10:39:21 -0400

> > This, IMHO, is the biggest blocker. While it "should be enough," to
> > know that we're improving the quality of the IETF's output, it's
probably
> not.
> > Maybe add the mentor as "editor," or create a new "editor," type slot
> > in the acks, or something like that?

> Russ, often we do agree on things -- but in this case, Yikes..... ;)

Just throwing ideas out. :-)

> could be the "RTG Dir document mentor".

Sure... This is what I'd advocate -- maybe some new "thing" we can put on
drafts beyond the author/co-author slot. "Editor," seems like a good point
of insertion, since that's really what we're mostly talking about (right? --
or maybe not?) -- someone who helps get the draft into some sort of shape
for publication, rather than someone who materially contributes to the
content of the draft itself (in technical terms). IE, I don't expect my
editors to actually contribute content, but rather to help me with places
where I've been unclear, or in asking questions that I've not answered, so I
can make certain the text covers everything that needs to be covered.

To some degree, I'm gravitating towards a "book editor" model, since that's
what I'm most familiar with.

> 2) Following the document authors through the review process (IETF LC, AD,
> IESG) is the job of the document shepherd.
> 
> 3) Following the document through the RFC Editor process is the job of the
> authors (and perhaps the ADs, in case of non-editorial edits).

> Sticking the "mentor" onto a document as an editor/co-author would also
> require the "mentor" to be part of 2) and 3) -- that seems to scale even
less
> well :)

Agreed on these points.

> Sticking the "mentor" onto a document as an editor/co-author is (imo)
> actually intellectually dishonest, and something I'd much ask to not have
> done to me, if I was a mentor of a doc. 

Which is precisely why I don't think this is the right thing to do... 

:-)

Russ

---

From: Alia Atlas <[email-masked]>
Date: Mon, 31 Mar 2014 10:40:35 -0400

Jamal and Russ,

We are not talking about assigning random people as document mentors.   We
are discussing having members of the Routing Directorate do this.  These
are people who have agreed to spend some of their time doing reviews and
helping support the IETF and the routing area.  If someone does not have
cycles or can only mentor a certain number of documents, that can be
articulated.

I do see the role of editor or author as being completely separated from a
document mentor.  There is no way for the document mentor to be or be
perceived as neutral if the document mentor is a co-author.

As far as benefits to the directorate member, presumably they see some good
reasons to have agreed.   Professional networking relationships, broadening
ones knowledge, helping support the IETF so that it continues to be a
healthy organization, etc.

That said - clearly having document mentors is a way of trying to address
the problems of inadequate review and difficulty in actively improving the
document when changes can be made.  If we kill even 1 in 2 WG drafts, that
is not something that I've seen...

Regards,
Alia

---

From: "Russ White" <[email-masked]>
Date: Mon, 31 Mar 2014 10:41:21 -0400

> what I'm most familiar with.

I'm not saying this is the right model, btw, just the one I'm familiar with,
so it's the easiest framework for me to put this discussion in to. I may
have the wrong framework entirely, and so my thinking might be completely
wrong.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Mon, 31 Mar 2014 10:45:10 -0400

> We are not talking about assigning random people as document mentors.

Of course... 

> perceived as neutral if the document mentor is a co-author.

I think the problem here might be the terminology -- I probably shouldn't
have chosen to say, "editor," since that actually already has a specific
meaning within the IETF context. But I'm not certain what else you could
call this role -- "mentor," doesn't seem right, as it seems to imply
something on a more personal level. "Shepherd," is already taken. "Editor"
might cause confusion...

Maybe "Copy Editor," or "Copyreader," or some such (those seem to be the
only suggestions from my large green creature wandering through the woods
never using one word when two or more will do -- thesaurus).

> As far as benefits to the directorate member, presumably they see some
> good reasons to have agreed.   Professional networking relationships,
> broadening ones knowledge, helping support the IETF so that it continues
to
> be a healthy organization, etc.

Sure -- and a lot of folks would volunteer silently just for these reasons.
OTOH, giving official recognition of some type would help bring people out
of the woodwork, and also provide a traction point for people who want this
sort of help with their drafts.

:-)

Russ

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 31 Mar 2014 14:51:26 +0000

On Mar 31, 2014, at 2:12 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

I think it is a fantastic idea -- arguably it is front-loading some of the collective workload, as better documents should be produced to be reviewed for others to review later.

I think the aded workload is worth it.

Thanks,

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 31 Mar 2014 14:54:49 +0000

>> investment for the mentor.

Giving back to the community?

Carlos.

---

From: "Russ White" <[email-masked]>
Date: Mon, 31 Mar 2014 11:24:52 -0400

> Giving back to the community?

This will work for some folks, but not for others. Some folks have to
justify time spent through their jobs, etc.; having some way to ack folks
who play this role would be helpful.

:-)

Russ

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 17:31:49 +0200

> who play this role would be helpful.

I think that I have vague memories of a section in some documents, titled "Acknowledgements". Might that be a place for the authors to express gratitude (at their leisure) to the mentor? 

I firmly believe that authors will know when to say "Special thanks to Russ White for his unfaltering support in seeing this document successfully from WG adoption to publication, and for providing strong guidance on how to best deal with ....", if indeed Russ White has been helpful (even, if he wasn't an official mentor).

On the other hand, I also firmly believe that no author should be obligated to say "Special thanks to Thomas Clausen" if, in fact, all that nefarious Thomas Clausen has done has been to make fun of document typos, just because he was the assigned official mentor....

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 31 Mar 2014 15:39:48 +0000

The way I read what is proposed below is that all documents will be assigned a mentor. Perhaps that is not what you intended - but it does seem to read that way. And as others who have replied to this have suggested that doesn't make sense for all documents and doesn't scale well. Also, the stated process introduces mentoring AFTER a document is adopted as a WG item. IMHO this is too late.

What I would suggest is that there become three options available for a WG to choose when a document is proposed as a WG item:

1)Accept
2)Reject
3)Resubmit after mentoring

The third category is reserved for documents which the WG feels have an idea/solution which might be worth the WG group's time, but the current "quality" of the document is such that meaningful discussion would be hindered.
The authors are free to reject the offer of mentoring in which case the document is rejected.

This limits the time/effort on the part of the mentors to a smaller number of documents and only for ones that are actually worth the time. Also, it means the time of the entire WG is not wasted on discussions that might be unnecessary if the draft presentation were improved. 

That said, the danger I see here is that in some cases it will be very hard for a mentor to provide meaningful feedback without also commenting on the guts of the solution. If the only issue is "grammar", then not a concern. But I think what we are trying to address may go beyond simply editorial/grammatical issues in some cases and then it is not clear to me how one separates "mentoring" from "authorship". 

   Les

> -----Original Message-----
> From: rtg-dir [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Monday, March 31, 2014 5:12 AM
> To: [email-masked]; [email-masked]
> Subject: [RTG-DIR] Document Mentors
> 
> Hi,
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 31 Mar 2014 11:40:46 -0400

I agree with what Thomas here.  I don't see a reason to institutionalize
and require acknowledgements.
There is already membership in the directorate; there would be the
association in the wiki.
It would also be helpful to hear from more Routing Directorate members if
they would be willing to do this
and from more WG chairs as to whether it could be useful.

Thanks,
Alia

On Mon, Mar 31, 2014 at 11:31 AM, Thomas Clausen
<[email-masked]>wrote:

> I think that I have vague memories of a section in some documents, titled
> "Acknowledgements". Might that be a place for the authors to express
> gratitude (at their leisure) to the mentor?
>
> I firmly believe that authors will know when to say "Special thanks to
> Russ White for his unfaltering support in seeing this document successfully
> from WG adoption to publication, and for providing strong guidance on how
> to best deal with ....", if indeed Russ White has been helpful (even, if he
> wasn't an official mentor).
>
> On the other hand, I also firmly believe that no author should be
> obligated to say "Special thanks to Thomas Clausen" if, in fact, all that
> nefarious Thomas Clausen has done has been to make fun of document typos,
> just because he was the assigned official mentor....
>
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 31 Mar 2014 11:51:45 -0400

Hi Les,

Thanks for your thoughts,

On Mon, Mar 31, 2014 at 11:39 AM, Les Ginsberg (ginsberg) <
[email-masked]> wrote:

> The way I read what is proposed below is that all documents will be
> assigned a mentor. Perhaps that is not what you intended - but it does seem
> to read that way. And as others who have replied to this have suggested
> that doesn't make sense for all documents and doesn't scale well. Also, the
> stated process introduces mentoring AFTER a document is adopted as a WG
> item. IMHO this is too late.
>

The process involves discussing having a document mentor.  If the WG chairs
and authors agree that there is no need, then no document mentor is
required.  It is intended to be expressly a check and decide against rather
than requiring an ask.  As for scaling, which aspect is the concern?
There are really about 200 WG drafts in the state where they'd have
document mentors and many of those wouldn't need them.   I am happy to
address scaling concerns - but I need to understand the parameters of
concern.

> What I would suggest is that there become three options available for a WG
> to choose when a document is proposed as a WG item:
>
> 1)Accept
> 2)Reject
> The third category is reserved for documents which the WG feels have an
> idea/solution which might be worth the WG group's time, but the current
> "quality" of the document is such that meaningful discussion would be
> hindered.
> This limits the time/effort on the part of the mentors to a smaller number
> of documents and only for ones that are actually worth the time. Also, it
> means the time of the entire WG is not wasted on discussions that might be
> unnecessary if the draft presentation were improved.
>

You are assuming that there is never any need for external review or to
improve drafts by review (outside the standard WG members) before WGLC.
The goal of the document mentor is to do early review and suggest
improvements and changes once the draft is under control of the IETF -
which individual drafts aren't.

For the case that you are suggesting, I feel like that belongs to the WG
chair to figure out getting the reviews and improvement needed.  It is
useful - of course! - but not the problem that this idea is trying to solve.

> That said, the danger I see here is that in some cases it will be very
> hard for a mentor to provide meaningful feedback without also commenting on
> the guts of the solution. If the only issue is "grammar", then not a
> concern. But I think what we are trying to address may go beyond simply
> editorial/grammatical issues in some cases and then it is not clear to me
> how one separates "mentoring" from "authorship".
>

This isn't a language review or an editing relationship!   This is
technical mentoring of the document - which includes making suggestions
during a review of how it can be improved.  Done well, I'd expect it to go
to acknowledgements.  I certainly review drafts and make significant
comments without expecting or needing to become an author.

Alia

> > We don't think that technology expertise is as useful in this as IETF
> clue
> > and

---

From: "Russ White" <[email-masked]>
Date: Mon, 31 Mar 2014 12:02:10 -0400

> gratitude (at their leisure) to the mentor?

Okay -- point taken... I'm fine with asking that an ack be included in the
ack's section.

:-)

Russ

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 31 Mar 2014 12:19:40 -0400

Hi Thomas,

> Personally, I am grateful enough for the work that was done by others in building the Internet, and the help I got from elder IETFers when I started in the IETF, to want to "pay it forward" a bit,…

I understand and empathize.

[sorry, snipping through rest of text]

>
> Essentially, you say that you prefer "spending time evaluating and rejecting a kernel-patch on submission" than >"spending time making sure that submitted kernel-patches are good".
>

Yes, because it has been proven to scale better.
I realize this approach is open to abuse as well - but thats a
different socio-economic
discussion.

> Well, I disagree there, I think at WG adoption is the right time. Just before shepherding step is (for
> all intents and purposes) the same as during IETF LC.
>

Ok, i will agree to disagree ;->

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 31 Mar 2014 12:21:21 -0400

Resubmit after mentoring may scale better. But i think you hit the
nail on the head with:
"But I think what we are trying to address may go beyond simply
editorial/grammatical issues"

Often the bad drafts require a total rewrite.

cheers,
jamal

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 18:21:38 +0200

> Ok, i will agree to disagree ;->

Fair enough, and perhaps we're both needed: I'll volunteer for the early mentoring, and you get to be the showstopper? :)

Cheers,

Thomas

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 31 Mar 2014 12:29:44 -0400

> Fair enough, and perhaps we're both needed: I'll volunteer for the early mentoring, and you get to

We are making progress and  I dont want to be a showstopper for this
discussion ;->

cheers,
jamal

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 18:33:53 +0200

> Often the bad drafts require a total rewrite.

In which case, that may *exactly* be what the WG chairs need to have an outsider to say in public:

	"I've read this I-D as part of <some boilerplate like the RTG-DIR review>

	 I find the ideas to be interesting, but the use of FOO to do BAR violates all
	 known architectural principles, and the laws of physics.

	 Also, language issues renders the document really, really hard to  read for
	 non-klingons

	 I would recommend that the authors discuss how they intend to do BAR
	 without violating the laws of physics and, if successful, that we look at if
	 the WG has somebody willing to help out with the language issues"

Short and easy and helpful. 

Of course, it may turn out that it is such a great idea that you'll *want* to be the person helping out with the language issues, to be able to claim contribution to it later - excellent, also, that WG just gained a very experienced participant.

I'm known as a chronic pessimist, and I really can't see any downsides here.

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 18:34:59 +0200

> We are making progress and  I dont want to be a showstopper for this

Alright, and I will add an acknowledgement to Russ White - I think that we're all winners.

So, ADs, when do we get our documents assigned? ;)

Thomas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Mar 2014 13:07:47 -0400

This reply raises explicitly a question that confused me reading 
Adrian's first note.  Is the target of this work drafts inside the 
routing area, or drafts from outside the routing area that have routing 
implications or concerns.

I had assumed that the target was the later.  Those are the ones that 
would not normally receive routing clue.  I had, possibly erroneously, 
assumed that most routing area work received sufficient routing 
assistance during its development.  To pick on my own routing area WG, 
if the KARP work is not receiving sufficient routing review, then that 
is my 9and my co-chair's) problem.  And we might ask for help.  But I 
would not expect us to ask for life-cycle assistance on our documents.
also, for many working groups, the drafts assume knowledge of other 
drafts.  And if the mentor needs to be that involved, they become a 
routing advisor.

Having said all that, I do agree that the directorate is lightly loaded, 
and I am happy to help by accepting more load.

Yours,
Joel

On 3/31/14, 10:18 AM, Alia Atlas wrote:
> Acee,
>
> Absolutely, this would be doing more work.  It would be doing it earlier
> in the draft life-cycle when there is a chance of improving or killing
> bad drafts that did make it past working group adoption.   Having better
> drafts coming out out of WGLC seems to me to be a clear win - easier to
> understand, better technology, common issues and nits addressed, faster
> to process through the endgame (IETF Last Call, IESG, IANA, etc).
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Mar 2014 14:40:18 -0400

> address scaling concerns - but I need to understand the parameters of

I'm wondering if a full-out mentor is really what is needed.

A significant amount of the work I think we're hoping to save can be caught
by competent technical editing even by persons somewhat unfamiliar with the
topic at hand:
- Is the document written in clear English?
- Are the concepts clearly explained?
...
- and *then*, are the concepts sound for the proposal for the technical work
  at hand?

Part of the pain each reader is expected to go through until the first two
points are satisfied is that their brains are having to work around the
editing.  The third point, when it's missing the "every person working in
the IETF should know" kind of points, is appropriate for a WG-neutral
mentor.  Beyond that, it's the work of the working group, IMO.

Thus, I think what's needed is more the ability to punch a button next to
the draft and say "this needs technical editing help" and potentially let
parties who are willing to volunteer be able to pick up the work. 

Compensation beyond egoboo[1] for such dirty work is the subject of a
different thread.  (Although I did poke IAOC about some sort of public
"karma" system over a year ago.)

-- Jeff

[1] http://en.wikipedia.org/wiki/Egoboo

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 31 Mar 2014 18:44:22 +0000

Alia -

Thanx for the reply.
Inline.

From: Alia Atlas [mailto:[email-masked]]
Sent: Monday, March 31, 2014 8:52 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] Document Mentors

Hi Les,

On Mon, Mar 31, 2014 at 11:39 AM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
The way I read what is proposed below is that all documents will be assigned a mentor. Perhaps that is not what you intended - but it does seem to read that way. And as others who have replied to this have suggested that doesn't make sense for all documents and doesn't scale well. Also, the stated process introduces mentoring AFTER a document is adopted as a WG item. IMHO this is too late.

The process involves discussing having a document mentor.  If the WG chairs and authors agree that there is no need, then no document mentor is required.  It is intended to be expressly a check and decide against rather than requiring an ask.  As for scaling, which aspect is the concern?   There are really about 200 WG drafts in the state where they'd have document mentors and many of those wouldn't need them.   I am happy to address scaling concerns - but I need to understand the parameters of concern.

LES: Documents that only need "a little bit of help" don't require mentoring. A comment from anyone on the list likely suffices.  Any document which requires mentoring wil demand a significant effort. Since the thread has openly discussed how many documents there are in routing  I took that (perhaps mistakenly) to mean mentoring was a new part of the process for all documents. If that is NOT the case and the percentage of documents which we think will require mentoring is small then I don't think scale is an issue - but the estimates here still seem to be vague.

1)Accept
2)Reject

You are assuming that there is never any need for external review or to improve drafts by review (outside the standard WG members) before WGLC.   The goal of the document mentor is to do early review and suggest improvements and changes once the draft is under control of the IETF - which individual drafts aren't.

LES:No - I make no such assumption. Nor am I suggesting that individual contributions get mentoring. I am suggesting that if someone asks for a document to become a WG document then at that time the WG should have an option to say

"Your document is addressing an area of interest to the WG but the current presentation/solution needs work in order to have a productive discussion. If you wish a mentor can be assigned to assist you in providing a document which is worthy of discussing in the WG."

Frankly I think this is the point where we can get the most return. Discussing documents which are seriously flawed (editorially or technically) is a waste of the WG time - as well as the authors. But if there is a good reason to move from individual contribution to WG document it makes a lot of sense to me to get the document into good shape BEFORE the entire WG spends cycles on it. That makes better use of the WG time. Mentoring can continue during WG review of course, but I like to think that if we start w WG-00 that is in good shape the version that passes last call is much more likely (and with much less additional effort) also going to be in good shape. This does not preclude or censure any WG comments post WG-00 submission of course - but hopefully we will all at least have a common understanding of what we are reviewing.

For the case that you are suggesting, I feel like that belongs to the WG chair to figure out getting the reviews and improvement needed.  It is useful - of course! - but not the problem that this idea is trying to solve.

LES: So you think WG review of a document that is in poor shape is not a problem? If the flaws of the document are only addressed AFTER the WG would have approved a last call what makes you think the WG understood what they were approving?

This isn't a language review or an editing relationship!   This is technical mentoring of the document - which includes making suggestions during a review of how it can be improved.  Done well, I'd expect it to go to acknowledgements.  I certainly review drafts and make significant comments without expecting or needing to become an author.

LES: This is NOT about getting credit.

ASIDE:
Speaking just for myself I don't give a damn whether I get credit for mentoring or not. If I wanted to become famous I would have chosen a different profession. :)
END ASIDE

I am saying that once you start discussing changes to thet technical solution the line between reviewer and author gets quite blurred. What then is the role difference between a mentor and a WG member who suggests a different way of solving the problem? One difference of course is that the mentor is specifically assigned to this document. But what makes the mentor's technical comments any more or less valid that that of of any other IETF member? (Answer: Nothing) So how then do you define the role of the mentor and why should the authors be bound to listen to the mentor any more than they would anyone else?

   Les

Alia

   Les

> From: rtg-dir [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Adrian Farrel
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Ross Callon <[email-masked]>
Date: Mon, 31 Mar 2014 19:14:43 +0000

Regarding Alia's comment:

> It would be doing it earlier in the draft life-cycle when there is a chance of improving or killing bad drafts that did make it past working group adoption...

I had been thinking of this "mentoring idea" as being distinct from a "one time review" role that the directorate allegedly already plays, and involves having mentors be helpful to inexperienced authors writing drafts about worthy ideas.

There are of course also some documents in the routing area that I might personally prefer to see die or quietly go away. However, having a mentor assigned to a document for an extended period of time and specifically try to kill a bad draft seems like a way to spend a lot of time and make people unhappy. Also, I doubt that the authors would be thrilled to have a mentor assigned who is hostile to their work (there must be *someone* active in the area who likes the work if it was adopted as a WG draft). I am skeptical regarding whether this proposal is a good way to kill bad drafts.

Thus I think that at least for the initial experiment if someone agrees to be a mentor for a document then they are sort of implicitly implying that there is a germ of value there that they would like to see go forward.

Ross

From: rtg-dir [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Monday, March 31, 2014 10:19 AM
To: Acee Lindem
Cc: Adrian Farrel; Jamal Hadi Salim; Thomas Heide Clausen; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] Document Mentors

Acee,

Absolutely, this would be doing more work.  It would be doing it earlier in the draft life-cycle when there is a chance of improving or killing bad drafts that did make it past working group adoption.   Having better drafts coming out out of WGLC seems to me to be a clear win - easier to understand, better technology, common issues and nits addressed, faster to process through the endgame (IETF Last Call, IESG, IANA, etc).

As for current scale, there are 187 WG drafts in routing plus 27 is IESG processing.  At the moment, the routing directorate is not highly loaded.

Alia

On Mon, Mar 31, 2014 at 9:40 AM, Acee Lindem <[email-masked]<mailto:[email-masked]>> wrote:
Hi Thomas, Jamal, and Adrian,
I agree with Jamal on scaling. There may not be an order of magnitude difference between the number of drafts accepted as WG documents and those that make it through WG last call but it is certainly some power of 2. Hence, we'd be increasing our workload by 2 to 4 times just in shear numbers without even taking into account the fact that the bad drafts will take much more time than the ones making it through WG last call.
Thanks,
Acee

On Mar 31, 2014, at 9:12 AM, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:

> Jamal,
>
> On 31 Mar 2014, at 14:48, Jamal Hadi Salim <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
>>> Hi,
>>>

---

From: Ross Callon <[email-masked]>
Date: Mon, 31 Mar 2014 19:19:53 +0000

It seems to me that if a document has experienced authors who are productive IETF regulars, then they probably don't need a mentor on an ongoing basis. They might benefit from a one-time review.

Thus the question: Would this be limited to documents with inexperienced authors? As WG chairs do we envision other reasons why a particular document might benefit from a mentor? (perhaps a document that needs a strong mathematician or a security expert or a link state routing expert to help with one section)? 

Ross

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, March 31, 2014 8:12 AM
To: [email-masked]; [email-masked]
Subject: [RTG-DIR] Document Mentors

Hi,

Thanks,
Adrian and Alia

=========

The Problems: 

The Goals:

  d) Quality documents.

The Solution:

The Expected Workload:

The Basic Process:

---

From: Alia Atlas <[email-masked]>
Date: Mon, 31 Mar 2014 16:04:44 -0400

Ross,

Recall that the idea for a Document Mentor was generated from the expressed
desire to have reviews done earlier
so that there could be actually technical impact and ability to request
fixes and improvements which are not possible
at IETF LC time.

I would be happy to see suggestions for improvements in the write-up that
Adrian sent out.

A document mentor is supposed to be neutral - not for or against before
hand - and is a mentor (maybe a better word?)
for the document, doing the two consistent reviews and suggesting how to
get the necessary sections in.

I think that WG chairs are currently empowered to refuse bad drafts, that a
few people thinking the idea may be ok
need not indicate that it should progress, and that additional good reviews
are useful.

Regards,
Alia

On Mon, Mar 31, 2014 at 3:14 PM, Ross Callon <[email-masked]> wrote:

> > It would be doing it earlier in the draft life-cycle when there is a
> chance of improving or killing bad drafts that did make it past working
> group adoption...
>
>
>
> I had been thinking of this "mentoring idea" as being distinct from a "one
> time review" role that the directorate allegedly already plays, and
> involves having mentors be helpful to inexperienced authors writing drafts
> about worthy ideas.
>
>
>
> There are of course also some documents in the routing area that I might
> personally prefer to see die or quietly go away. However, having a mentor
> assigned to a document for an extended period of time and specifically try
> to kill a bad draft seems like a way to spend a lot of time and make people
> unhappy. Also, I doubt that the authors would be thrilled to have a mentor
> assigned who is hostile to their work (there must be **someone** active
> in the area who likes the work if it was adopted as a WG draft). I am
> skeptical regarding whether this proposal is a good way to kill bad drafts.
>
>
>
> Thus I think that at least for the initial experiment if someone agrees to
> be a mentor for a document then they are sort of implicitly implying that
> there is a germ of value there that they would like to see go forward.
>
>
>
> Ross
>
>
>
> *From:* rtg-dir [mailto:[email-masked]] *On Behalf Of *Alia
> Atlas
> *Sent:* Monday, March 31, 2014 10:19 AM
> *To:* Acee Lindem
> *Cc:* Adrian Farrel; Jamal Hadi Salim; Thomas Heide Clausen;
> [email-masked]; [email-masked]
> *Subject:* Re: [RTG-DIR] Document Mentors
>
>
>
> Acee,
>
>
>
> in the draft life-cycle when there is a chance of improving or killing bad
> clue and

---

From: Alia Atlas <[email-masked]>
Date: Mon, 31 Mar 2014 16:15:12 -0400

Ross,

On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon <[email-masked]> wrote:

> It seems to me that if a document has experienced authors who are
> productive IETF regulars, then they probably don't need a mentor on an
> ongoing basis. They might benefit from a one-time review.
>

Yes, if you look at the problem and goals, they apply to most documents.
 Get good solid reviews early in the process (WG adoption) and late (WGLC)
and then work with the authors to make sure that the technical issues are
dealt with early enough to have impact.

Perhaps if you look at the process less as mentor and more as "dedicated
document reviewer"?

>
> Thus the question: Would this be limited to documents with inexperienced
> authors? As WG chairs do we envision other reasons why a particular
> document might benefit from a mentor? (perhaps a document that needs a
> strong mathematician or a security expert or a link state routing expert to
> help with one section)?

I'd be interested in what others' perspectives are.   When are reviews of
drafts useful?  What text would you change?

Regards,
Alia

---

From: Ross Callon <[email-masked]>
Date: Mon, 31 Mar 2014 20:16:55 +0000

I thought that the directorate members were already document reviewers, but doing one-time reviews rather than following a document throughout its journey.

Ross

From: Alia Atlas [mailto:[email-masked]]
Sent: Monday, March 31, 2014 4:15 PM
To: Ross Callon
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] Document Mentors

Ross,

On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon <[email-masked]<mailto:[email-masked]>> wrote:
It seems to me that if a document has experienced authors who are productive IETF regulars, then they probably don't need a mentor on an ongoing basis. They might benefit from a one-time review.

Yes, if you look at the problem and goals, they apply to most documents.  Get good solid reviews early in the process (WG adoption) and late (WGLC) and then work with the authors to make sure that the technical issues are dealt with early enough to have impact.

Perhaps if you look at the process less as mentor and more as "dedicated document reviewer"?

I'd be interested in what others' perspectives are.   When are reviews of drafts useful?  What text would you change?

Regards,
Alia

Ross

-----Original Message-----
From: rtg-dir [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Adrian Farrel
Sent: Monday, March 31, 2014 8:12 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [RTG-DIR] Document Mentors
Hi,

Thanks,
Adrian and Alia

=========

The Problems:

The Goals:

  d) Quality documents.

The Solution:

The Expected Workload:

The Basic Process:

---

From: Alia Atlas <[email-masked]>
Date: Mon, 31 Mar 2014 16:27:20 -0400

On Mon, Mar 31, 2014 at 4:16 PM, Ross Callon <[email-masked]> wrote:

>  I thought that the directorate members were already document reviewers,
> but doing one-time reviews rather than following a document throughout its
> journey.
>

Yes - and the one-time reviews happen at IETF LC or so - based on AD
need/request.
This is pushing it earlier, with the expectation that the reviewer will
also push the technical concerns,
and then a review later at WGLC.

Alia

>
>
> Ross
>
>
>
> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Monday, March 31, 2014 4:15 PM
> *To:* Ross Callon
>
> *Cc:* [email-masked]; [email-masked]; [email-masked]

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 23:29:34 +0200

> On 31 mars 2014, at 22:15, Alia Atlas <[email-masked]> wrote:
> 
> Ross,
> 

That may kinda be a good term as such - nobody gets too old and too experienced to benefit from a review and a sanity-check from another IETFer, whereas experienced authors may not need any "mentoring".

I'd feel, for example, perfectly happy giving Ross a review of a document, and even do it twice or thrice - but yeah, it'd fe "odd" being designated a  "mentor" for his document...egg teaching the rooster, and all that.

> I'd be interested in what others' perspectives are.   When are reviews of drafts useful?  What text would you change?

Personally? Well, the more reviews the happier I am ....

Realistically: whenever a document reaches a "stable state", or whenever I'm stuck.

In a perfect world: already when I have the outline and the idea ready, and from people with different specialities...security-guidance even before putting pen to paper would, for example.

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 23:43:45 +0200

> On 31 mars 2014, at 22:27, Alia Atlas <[email-masked]> wrote:
> 
> Yes - and the one-time reviews happen at IETF LC or so - based on AD need/request.
> This is pushing it earlier, with the expectation that the reviewer will also push the technical concerns,

I am repeating myself, but to me that is *exactly* the right thing to do. 

As an author, it is immensely more helpful getting a review when you start, and use that to guide the document development, than it is to get a review when you feel that you already have crossed the finishing line.

Also as an author, it's often hard to coerce anybody to give a review before a document reaches WGLC/IETF LC and there's a formal deadline set.

And, as an author, having an external pair of eyes who has a priori kinda promised to "be available, as needed, and give the occasional review" to solicit on occasion, is quite handy.

I'm repeating myself, but my opinion is "let's give it a shot, and check back in in due time".

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 31 Mar 2014 23:46:07 +0200

> On 31 mars 2014, at 23:43, Thomas Heide Clausen <[email-masked]> wrote:
> 
> 
argh... 

s/anybody/anybody from outside the working group/

s/give a review/give a detailed review/