Subject: [RTG-DIR] Routing Area Health Check

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Mar 2014 18:31:08 -0000

Hello Directorate and WG chairs,

Alia and I have been discussing the Routing Area, its work, its output, and its
working groups.

We have reached a conclusion (which perhaps we should have come to sooner) that
we need your help and input.

The crunch question for us is "What makes it hard to get work done in the
Routing Area?" What gets in the way of your work? What is making life hard for
document authors? How could working groups be doing better? We are open to all
and every type of answer. We are happy to have quick, one-line answers or
deeply-considered essays.

What do you think? 

Thanks for all your input,
Adrian and Alia

PS Please respond to both aliases because not everyone is on both lists. Sorry
that that means some of you will get duplicates.

---

From: John E Drake <[email-masked]>
Date: Fri, 21 Mar 2014 20:44:28 +0000

Adrian,

Combine IS-IS and OSPF

Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there

There is probably some synergy between PCE, SFC, and SPRING that needs to be exploited

Combine BFD and the OAM/protection switching part of MPLS

Close Secure IDR, FORCES, KARP, MANET, and NVO3 

Yours Irrespectively,

John

> -----Original Message-----
> From: rtg-dir [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Friday, March 21, 2014 11:31 AM
> To: [email-masked]; [email-masked]
> Cc: Alia Atlas
> Subject: [RTG-DIR] Routing Area Health Check
> 
> We have reached a conclusion (which perhaps we should have come to sooner)
> that we need your help and input.
> 
> Routing Area?" What gets in the way of your work? What is making life hard
> for document authors? How could working groups be doing better? We are
> open to all and every type of answer. We are happy to have quick, one-line
> answers or deeply-considered essays.
> 
> What do you think?
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 22 Mar 2014 03:35:17 +0000

Hi Adrian, Alia,

Require drafts to place more emphasis on OAM  to minimize OAM needing to play the catch-up game later.

Regards,
Nobo

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Friday, March 21, 2014 2:31 PM
> Subject: Routing Area Health Check
> 
> We have reached a conclusion (which perhaps we should have come to
> sooner) that we need your help and input.
> 
> PS Please respond to both aliases because not everyone is on both lists.
> Sorry that that means some of you will get duplicates.

---

From: Loa Andersson <[email-masked]>
Date: Sat, 22 Mar 2014 11:15:26 +0100

John,

How about deciding what is broken first, and then looking at the
actions??

/Loa

-- 

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

---

From: John E Drake <[email-masked]>
Date: Sat, 22 Mar 2014 12:22:05 +0000

Loa,

That's what I did.

Yours Irrespectively,

John

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Saturday, March 22, 2014 3:15 AM
> To: John E Drake; [email-masked]; [email-masked]; [email-masked]
> Cc: Alia Atlas
> Subject: Re: [RTG-DIR] Routing Area Health Check
> 
> John,
> 
> How about deciding what is broken first, and then looking at the actions??
> 
> /Loa
> 
> >> Alia and I have been discussing the Routing Area, its work, its
> >> output, and its working groups.
> >>
> >> The crunch question for us is "What makes it hard to get work done in
> >> the Routing Area?" What gets in the way of your work? What is making
> >> life hard for document authors? How could working groups be doing
> >> better? We are open to all and every type of answer. We are happy to
> >> have quick, one-line answers or deeply-considered essays.
> >>
> >> What do you think?
> >>
> >> PS Please respond to both aliases because not everyone is on both
> >> lists. Sorry that that means some of you will get duplicates.
> >>
> >>
> >
> >
> 
> --
> 
>

---

From: "Russ White" <[email-masked]>
Date: Sat, 22 Mar 2014 09:54:40 -0400

> > > Combine IS-IS and OSPF

I'm ambivalent about this... There is always an ebb and flow of work in
these WG's -- and it's going to be hard to separate them once they're
merged. OTOH, it does seem most of the work in both of these WGs is common
right now, and combining them might result in some interesting ideas (a
combined tlv for both protocols might be interesting).

> > > Close Secure IDR, FORCES, KARP, MANET, and NVO3

SIDR has "finished," the RPKI, which could be folded into IDR, and the path
protection stuff is a science experiment that isn't deployable in the real
world. Suggest moving the path protection work into the routing research
group until something that will actually provide some real protection comes
along.

> Require drafts to place more emphasis on OAM  to minimize OAM needing to
play the catch-up game later.

An interesting idea... Maybe we need something more concrete here, though,
like (as a rough start): require all new data structures in proposed
standards (or experimentals) include a data model in YANG format -- or some
such.

:-)

Russ

---

From: Ines Robles <[email-masked]>
Date: Sat, 22 Mar 2014 12:26:52 -0300

*Hi, About this: ""What is making life hard for document authors? How could
working groups be doing better?" I was thinking that maybe having some kind
of fast checklist for the authors, which they can follow to know about the
process on their documents. E.g.: When a new draft is submitted a checklist
could be displayed to download. In the checklist: "Before complete this
checklist, please be sure, that you have read RFC(list of related RFCs with
the IETF process.....) Checklist: When a new work is presented: * Did I
express my work's intention in the ML? * Did I find how it is related with
the current charter? Should I propose recharter, Why? * Did I present to
the ML some implementations about it? * Did I attend to a document language
session in the IETF? (for not native english speaker) ..... When a work is
ready to be published: * Did I address the SecDir review? * Did I address
the Gen-art review? * Did I address all open tickets? ....." It would not
replace the useful and necessary work of the Doc. Shepherds, it should give
just a fast review by the authors for themselves. Considering that the
authors are very busy most of the time, it should be a fast checklist, with
the main points to be considered. It is just an idea, I hope you can find
it useful :-) Thanks and Regards, Ines.*

2014-03-21 15:31 GMT-03:00 Adrian Farrel <[email-masked]>:

> for
> Sorry

---

From: "Russ White" <[email-masked]>
Date: Sat, 22 Mar 2014 12:55:12 -0400

> About this: ""What is making life hard for document authors? How could
> working groups be doing better?"

Another point we might want to consider is whether or not we should be at
least something proactive about the language barrier issues -- like making
certain the community knows the RG-DIR is open to helping folks with issues
on the language side, or even to provide a "non-native speaker review." This
might help improve the output of the area as a whole (?).

:-)

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 22 Mar 2014 13:01:23 -0400

John,
     Despite your asserting that you had decided what was broken, I can 
not see the relationship between your asserted fixes and any of the 
questions in Adrian's initial note.
      I can guess, for example, that you think the number of working 
groups is itself a problem.  But that is a guess.  You don't even assert 
it, much less justify it.
     Yours,
     Joel

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 22 Mar 2014 18:26:15 +0100

I recently did some language editing on a draft I was technically
reviewing for the Independent Series Editor (the author wasn't a
native English speaker). Perhaps we could put together a list of area
volunteers that are willing to do a language cleanup pass on drafts
that could use it just before they go into WG LC. You wouldn't want to
do it any earlier.

Cheers,
Andy

---

From: "Russ White" <[email-masked]>
Date: Sat, 22 Mar 2014 13:28:40 -0400

> I recently did some language editing on a draft I was technically
reviewing for
> the Independent Series Editor (the author wasn't a native English
speaker).
> Perhaps we could put together a list of area volunteers that are willing
to do
> a language cleanup pass on drafts that could use it just before they go
into
> WG LC. You wouldn't want to do it any earlier.

I'd be glad to help out with this...

:-)

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 22 Mar 2014 13:37:51 -0400

Andy and Russ

I will be glad to help out as well. 

Sue

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 22 Mar 2014 18:44:44 +0000

Hi,

I may see a couple elements:

- Protocol evolution: one starts with a basic specification and progressively come up with evolutions in separate documents that come with their own extensions, etc. while there are very few documents providing global picture or tentatives to consolidate the protocol specifications; the dependency graph may help but remains limited. 

- RFC document results of sometimes complex reasoning which may remain undocumented -> those that were part of the inner-discussions know why, newcomers not necessarily. I would also state here that the format/messaging part is often taking over the procedural part in description.

- Are emails/ftp still the best way to exchange technical content ? in particular reviewing/updating documents ? Once reaching working group status it could be valuable to progress documents with collaborative writing tools.

Thanks,
-dimitri.

> Sent: Friday, March 21, 2014 19:31

---

From: Lou Berger <[email-masked]>
Date: Sat, 22 Mar 2014 14:45:29 -0400

This is a great idea.

Lou

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 22 Mar 2014 19:11:11 +0000

> From: rtg-dir [mailto:[email-masked]] On Behalf Of Russ White
> Sent: Saturday, March 22, 2014 14:55
> To: 'John E Drake'; 'Loa Andersson'; [email-masked]; rtg-
> [email-masked]; [email-masked]
> Cc: 'Alia Atlas'
> group until something that will actually provide some real protection
> comes along.

... I think the problem is broader here, how to ensure a better cooperation with RRG (bidirectional)

There is closer relation between ICCRG (with groups transport and congestion control) and TSV Area so we could certainly do better here.

Thanks,
-d.

---

From: Acee Lindem <[email-masked]>
Date: Sat, 22 Mar 2014 22:18:12 +0000

I agree with Loa that the problem needs to be defined - this discussion
has already diverged into 4 different directions.

Thanks,
Acee 

On 3/22/14 3:15 AM, "Loa Andersson" <[email-masked]> wrote:

>>>the
>>>lists. Sorry

---

From: Alia Atlas <[email-masked]>
Date: Sat, 22 Mar 2014 18:48:22 -0400

Acee,

None of those different directions seems to me to be bad.
The question was deliberately ask unframed and undefined.
Adrian and I will define and frame it more - but first we wanted
to hear the unframed but thoughtful discussion.

Providing reasoning does help everyone determine if they are
on the same page.

Regards,
Alia

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 22 Mar 2014 22:09:27 +0000

> > Require drafts to place more emphasis on OAM  to minimize OAM needing
> > to
> An interesting idea... Maybe we need something more concrete here,
> though, like (as a rough start): require all new data structures in proposed
> standards (or experimentals) include a data model in YANG format -- or
> some such.
> 
> :-)
> 
> Russ

Requiring data model (MIB/YANG) wasn't what I had in mind, although that itself is an interesting idea.

I was thinking more from different angle.

Picking on recent specific.

http://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-ingress-protection/?include_text=1

   Ra should be able to detect the failure of R1 and switch the traffic
   within 10s of ms.  The exact method by which Ra does so is out of
   scope.

How? Ra cannot differentiate between failure of link/reachability to R1 versus node failure of R1, and proposed solution will not work w/o differentiating the two. "should be able to detect" here sounds more like "someone will probably do something later".

I rather see "OAM Considerations" section describe things needed/required in OAM tools for the proposal to work. If that can also be communicated to <somewhere where OAM guys can provide feedback>, even better.

Regards,
Nobo

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 22 Mar 2014 22:29:55 +0000

I agree with Loa and Acee - let's define problems before trying to solve
them!

Cheers,
Jeff

-----Original Message-----
From: Acee Lindem Lindem III <[email-masked]>
Date: Saturday, March 22, 2014 3:18 PM
To: Loa Andersson <[email-masked]>, John Drake <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Alia Atlas <[email-masked]>
Subject: Re: [RTG-DIR] Routing Area Health Check
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>, <[email-masked]>,
"[email-masked]" <[email-masked]>, Joel Halpern
<[email-masked]>, <[email-masked]>, <[email-masked]>,
<[email-masked]>, Thomas Morin <[email-masked]>, Martin
Vigoureux <[email-masked]>,
<[email-masked]>, <[email-masked]>, <[email-masked]>, Loa
Andersson <[email-masked]>, <[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>, Acee Lindem Lindem
III <[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>, Alvaro Retana
<[email-masked]>, Jeff Tantsura <[email-masked]>,
<[email-masked]>, <[email-masked]>, <[email-masked]>,
<[email-masked]>, Alvaro Retana <[email-masked]>,
<[email-masked]>, Alia Atlas <[email-masked]>, <[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Mar 2014 08:36:59 -0000

Yeah, I like that all sorts of ideas are being thrown into the pot. We should be
a sufficiently adult subset of the crazies to be able to handle that.
 
However, we are talking like engineers :-)
Might be nice to focus back on the questions of what is a problem for getting
work done. We can come back to how to fix it.
 
Now, all of you complaining that the problem needs to be defined...
...please define the problem :-)
 
Adrian
 
From: Alia Atlas [mailto:[email-masked]] 
Sent: 22 March 2014 22:48
To: Acee Lindem
Cc: Loa Andersson; John E Drake; [email-masked]; [email-masked];
[email-masked]; Alia Atlas
Subject: Re: [RTG-DIR] Routing Area Health Check
 
Acee,

 
Regards,
Alia
 
On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem <[email-masked]> wrote:
I agree with Loa that the problem needs to be defined - this discussion
has already diverged into 4 different directions.

Thanks,
Acee

>>> that that means some of you will get duplicates.
<tel:%2B46%20739%2081%2021%2064>

---

From: "VIGOUREUX, MARTIN (MARTIN)" <[email-masked]>
Date: Sun, 23 Mar 2014 15:14:09 +0000

mpls has just started that following London's meeting.
Team of ~8 reviewers. First English review ongoing.

There were signs indicating the need for that.
Adrian's talk in mpls triggered the call for volunteers.

I think it is a good idea, especially if it enables to catch those sentences which can be understood technicaly differently.

-m
________________________________
De : Lou Berger
Envoyé : 22/03/2014 19:45
À : Andrew G. Malis; Russ White
Cc : Adrian Farrel; Ines Robles; Alia Atlas; [email-masked]; [email-masked]
Objet : Re: [RTG-DIR] Routing Area Health Check

This is a great idea.

Lou

---

From: Ines Robles <[email-masked]>
Date: Sun, 23 Mar 2014 11:19:32 -0300

*Hi, About this: "What is making life hard for document authors?" Maybe,
one problem is that the authors don't know all the steps, that a document
goes through during the process of publication, of course it is
responsibility of the authors read the required information to learn about
it; This is the minimum thing, that an author must do, if he/she wants to
publish a document in the IETF. But, I think, sometimes the authors believe
that, the work is done when a document is submitted to the IESG, then for
example they forget to address the Gen-art review, AUTH48, and additionals
reviews. Thinking that maybe, a fast checklist is going to help them to
know what they should address to get a document published :-) Thanks and
Regards Ines*

2014-03-23 5:36 GMT-03:00 Adrian Farrel <[email-masked]>:

> Yeah, I like that all sorts of ideas are being thrown into the pot. We
> should be a sufficiently adult subset of the crazies to be able to handle
> that.
>
>
>
> Might be nice to focus back on the questions of what is a problem for
> getting work done. We can come back to how to fix it.
>
>
>
> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* 22 March 2014 22:48
> *To:* Acee Lindem
> *Cc:* Loa Andersson; John E Drake; [email-masked]; [email-masked];
> *Subject:* Re: [RTG-DIR] Routing Area Health Check
>
>
>
> Acee,
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Mar 2014 17:21:02 -0000

> Adrian's talk in mpls triggered the call for volunteers.

For those who love learning how to suck eggs...
http://www.ietf.org/proceedings/89/slides/slides-89-mpls-15.pptx

A

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Mar 2014 09:49:15 -0400

> group until something that will actually provide some real protection comes

While I agree that the bgpsec stuff isn't deployable now (too much crypto),
it's at least sound design.  Probably best to just leave SIDR alone until
that component hits RFC rather than trying to dump the remaining work into
IDR.

> standards (or experimentals) include a data model in YANG format -- or some

I'm of mixed opinion about this from an IETF requirements standpoint.  As
much as I think we do a poor job of this sort of thing, protocol designers
tend to implement protocol management components.  Operators are far more
interested in what helps them diagnose why things don't work in their
networks.  The two functional requirements don't always meet well in the
middle.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Mar 2014 10:04:14 -0400

> deeply-considered essays.

Focusing on the "done" part through a bunch of random observations:
Work that gets "done" fast tends to be of interest and has running code
associated with it.  The authors are often working directly with
implementors.  In such cases, specs turn to implementations (or vice versa)
and we end up with RFCs quickly.

Something that has narrow focus can get published faster.

Work that is progressing but isn't finishing often has running code (perhaps
long deployed), but the interest of the authors/chairs in getting the thing
pushed to RFC is the problem.  A big portion of this, IMO, is due to the
entirety of the process taking too long.  Much of the fix for this is
probably the chairs pushing the work (more active chairs).

Work that lingers but isn't advancing (the walking dead) seems to have two
aspects (at least):
- Pet projects that haven't quite gotten some form of internal support to
  get code in an implementation.
- Something that is the "right thing" to do but no one is really interested
  in.

IMO, there is value to both of these, but they have a draining effect on
working group throughput.  This puts a lot of work upon either the authors
or the chairs to make sure that time only is used by the WG when it's not a
distraction.

---

>From the above, the big issue with chair activity probably comes down to the
fact that many chairs do not do IETF as their "full-time job".  It's a
common issue with volunteer organizations.  Things that help is better
project management tools (the datatracker helps but there's nothing in it
that fulfills project management functions rather than project artifact
tracking).  In the absence of tools, nags from above can help but our
leadership is similarly overwhelmed.

Pushing on the authors for certain types of work probably doesn't help.
Until there is implementation helping to pull things along, it's a "pushing
the rope" problem.

IMO, the fix for some of this is to ensure that at least meeting time is
reserved for active work.  Speculative or prospective work should be
required to be vetted in the mailing list first.  Walking dead work should
be reserved to the mailing list until it gains new life.

-- Jeff

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Mon, 24 Mar 2014 14:53:13 +0000

To my surprise, when I called for English review volunteers, we got many responses within the first three days.  About half were folks that never attend the IETF, but follow the mail list.  Most of these said that they were looking for a way to get more involved, but having no direct experience were too shy to speak up on technical issues.

I'm hoping this means we have a set of fairly highly motivated reviewers.  We'll let you know how it works out.

George

From: <VIGOUREUX>, "MARTIN (MARTIN)" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, March 23, 2014 11:14 AM
To: Lou Berger <[email-masked]<mailto:[email-masked]>>, "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>>, Russ White <[email-masked]<mailto:[email-masked]>>
Cc: Adrian Farrel <[email-masked]<mailto:[email-masked]>>, Ines Robles <[email-masked]<mailto:[email-masked]>>, Alia Atlas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [RTG-DIR] Routing Area Health Check
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Lou Berger <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "John G. Scudder" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "Bitar, Nabil N" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, George Swallow <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[email-masked]<mailto:[email-masked]>>, Ross Callon <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, BOCCI Matthew <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Julien Meuric <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, BOCCI Matthew <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "John G. Scudder" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Resent-Date: Sunday, March 23, 2014 11:14 AM

-m
Cc : Adrian Farrel; Ines Robles; Alia Atlas; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

This is a great idea.

Lou

On March 22, 2014 1:28:15 PM "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>> wrote:

> On Sat, Mar 22, 2014 at 5:55 PM, Russ White <[email-masked]<mailto:[email-masked]>> wrote:
> >

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Mar 2014 09:12:05 +1100

> group until something that will actually provide some real protection comes

Only if you are using the term "finished" in the sense of "not finished". :-)

There are, as far as I can see, outstanding with validation, local repository cache management, signalling, as well as path protection that tend to suggest "unsafe to deploy" to me.

Sometimes progress is hard in the routing area because we put impediments in our way and tend to concentrate on the self-imposed impediments of process over substance. On the other hand sometimes progress is hard because we don't adequately understand the problem space, and then we get confused over the difference between progress and motion. Exhorting participants for more rapid outcomes and stirring up activity often generates just motion, and then the undoing of this motion and trying to identify actual achievements and directions where progress can actually be made becomes downright difficult.

---

From: John E Drake <[email-masked]>
Date: Mon, 24 Mar 2014 23:32:42 +0000

"Never confuse movement with action" is one of Hemingway's most popular quotations and is included in the book, Neverisms: A Quotation Lover's Guide to Things You Should Never Do, Never Say, or Never Forget.

Yours Irrespectively,

John

> From: rtg-dir [mailto:[email-masked]] On Behalf Of Geoff Huston
> Sent: Monday, March 24, 2014 3:12 PM
> To: [email-masked]
> > SIDR has "finished," the RPKI, which could be folded into IDR, and the
> > path protection stuff is a science experiment that isn't deployable in
> > the real world. Suggest moving the path protection work into the
> > routing research group until something that will actually provide some
> > real protection comes along.
> 
> 
> There are, as far as I can see, outstanding with validation, local repository
> cache management, signalling, as well as path protection that tend to suggest
> "unsafe to deploy" to me.
> 
> Sometimes progress is hard in the routing area because we put impediments
> in our way and tend to concentrate on the self-imposed impediments of
> process over substance. On the other hand sometimes progress is hard
> because we don't adequately understand the problem space, and then we get
> confused over the difference between progress and motion. Exhorting
> participants for more rapid outcomes and stirring up activity often generates
> just motion, and then the undoing of this motion and trying to identify actual
> achievements and directions where progress can actually be made becomes
> downright difficult.
> 
> 
>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 25 Mar 2014 04:22:39 +0000

Perhaps would be worthwhile to present Adrian's presentation "What makes for a quality RFC" for every wg.

Cheers,
Jeff

From: Ines Robles <[email-masked]<mailto:[email-masked]>>
Date: Sunday, March 23, 2014 7:19 AM
To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Alia Atlas <[email-masked]<mailto:[email-masked]>>
Subject: Re: [RTG-DIR] Routing Area Health Check
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Joel Halpern <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Thomas Morin <[email-masked]<mailto:[email-masked]>>, Martin Vigoureux <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Acee Lindem Lindem III <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Alvaro Retana <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Alvaro Retana <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Alia Atlas <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>

Hi,

About this: “What is making life hard for document authors?”

Maybe, one problem is that the authors don’t know all the steps, that a document goes through during the process of publication, of course it is responsibility of the authors read the required information to learn about it; This is the minimum thing, that an author must do, if he/she wants to publish a document in the IETF.

But, I think, sometimes the authors believe that, the work is done when a document is submitted to the IESG, then for example they forget to address the Gen-art review, AUTH48, and additionals reviews.

Thinking that maybe, a fast checklist is going to help them to know what they should address to get a document published :-)

Thanks and Regards

Ines

2014-03-23 5:36 GMT-03:00 Adrian Farrel <[email-masked]<mailto:[email-masked]>>:
Yeah, I like that all sorts of ideas are being thrown into the pot. We should be a sufficiently adult subset of the crazies to be able to handle that.

However, we are talking like engineers :-)
Might be nice to focus back on the questions of what is a problem for getting work done. We can come back to how to fix it.

Adrian

From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 22 March 2014 22:48
To: Acee Lindem
Cc: Loa Andersson; John E Drake; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alia Atlas
Subject: Re: [RTG-DIR] Routing Area Health Check

Acee,

Regards,
Alia

On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Loa that the problem needs to be defined - this discussion
has already diverged into 4 different directions.

Thanks,
Acee

On 3/22/14 3:15 AM, "Loa Andersson" <[email-masked]<mailto:[email-masked]>> wrote:

>>> 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]>
>>> Cc: Alia Atlas
>Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
>Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
>Huawei Technologies (consultant)     phone: +46 739 81 21 64<tel:%2B46%20739%2081%2021%2064>
>

---

From: Ines Robles <[email-masked]>
Date: Tue, 25 Mar 2014 01:30:10 -0300

+1

---

From: Loa Andersson <[email-masked]>
Date: Tue, 25 Mar 2014 11:03:59 +0100

Acee,

a better idea than doing it once in ever wg. I also like the initiative
from Andy to send out the link to Adrians slides:

More wg chairs could do that

/Loa.

On 2014-03-25 10:44, Acee Lindem wrote:
>
> On Mar 25, 2014, at 12:22 AM, Jeff Tantsura <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> How about simply replaying it once in the Routing Area Open Meeting?
>
> Acee
>
>>
>>
>> Cheers,
>> Jeff
>>
>> To: Adrian Farrel <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>, "[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>, Alia Atlas <[email-masked]
>> <mailto:[email-masked]>>
>> Resent-To: <[email-masked] <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>,
>> <[email-masked] <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, "[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>, Joel Halpern <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>,
>> <[email-masked] <mailto:[email-masked]>>,
>> <[email-masked] <mailto:[email-masked]>>, Thomas Morin
>> <[email-masked] <mailto:[email-masked]>>, Martin
>> Vigoureux <[email-masked]
>> <mailto:[email-masked]>>,
>> <[email-masked] <mailto:[email-masked]>>,
>> <[email-masked] <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, Loa Andersson <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, Acee Lindem Lindem III
>> <[email-masked] <mailto:[email-masked]>>,
>> <[email-masked] <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, Alvaro Retana <[email-masked]
>> <mailto:[email-masked]>>, Jeff Tantsura <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, Alvaro Retana <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, Alia Atlas <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>
>>
>>> *
>>> Hi,
>>>
>>> Maybe, one problem is that the authors don’t know all the steps, that
>>> a document goes through during the process of publication, of course
>>> it is responsibility of the authors read the required information to
>>> learn about it; This is the minimum thing, that an author must do, if
>>> he/she wants to publish a document in the IETF.
>>>
>>> But, I think, sometimes the authors believe that, the work is done
>>> when a document is submitted to the IESG, then for example they
>>> forget to address the Gen-art review, AUTH48, and additionals reviews.
>>>
>>> Thinking that maybe, a fast checklist is going to help them to know
>>> what they should address to get a document published :-)
>>>
>>> Thanks and Regards
>>>
>>> Ines*
>>>
>>>
>>>> Yeah, I like that all sorts of ideas are being thrown into the pot.
>>>> We should be a sufficiently adult subset of the crazies to be able
>>>> to handle that.____
>>>> __ __
>>>> However, we are talking like engineers :-)____
>>>> Might be nice to focus back on the questions of what is a problem
>>>> for getting work done. We can come back to how to fix it.____
>>>> __ __
>>>> Now, all of you complaining that the problem needs to be defined...____
>>>> ...please define the problem :-)____
>>>> __ __
>>>> Adrian____
>>>> __ __
>>>> *From:*Alia Atlas [mailto:[email-masked] <mailto:[email-masked]>]
>>>> *Cc:* Loa Andersson; John E Drake; [email-masked]
>>>> <mailto:[email-masked]>; [email-masked]
>>>> <mailto:[email-masked]>; [email-masked]
>>>> <mailto:[email-masked]>; Alia Atlas
>>>> *Subject:* Re: [RTG-DIR] Routing Area Health Check____
>>>> __ __
>>>> Acee,____
>>>> __ __
>>>> None of those different directions seems to me to be bad.____
>>>> The question was deliberately ask unframed and undefined.____
>>>> Adrian and I will define and frame it more - but first we wanted ____
>>>> to hear the unframed but thoughtful discussion.____
>>>> __ __
>>>> Providing reasoning does help everyone determine if they are____
>>>> on the same page.____
>>>> __ __
>>>> Regards,____
>>>> Alia____
>>>>
>>>> __ __
>>>>
>>>> On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem
>>>> <[email-masked] <mailto:[email-masked]>> wrote:____
>>>> Acee____
>>>> On 3/22/14 3:15 AM, "Loa Andersson" <[email-masked] <mailto:[email-masked]>>
>>>> wrote:
>>>>
>>>> >John,
>>>> >
>>>> >>> 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]>
>>>> >>> Cc: Alia Atlas
>>>> >Loa Andersson                        email:[email-masked] <mailto:[email-masked]>
>>>> >Senior MPLS [email-masked] <mailto:[email-masked]>
>>>> >Huawei Technologies (consultant)     phone:+46 739 81 21 64 <tel:%2B46%20739%2081%2021%2064>
>>>> >____
>>>>
>>>> __ __
>>>
>

--

---

From: Acee Lindem <[email-masked]>
Date: Tue, 25 Mar 2014 09:44:28 +0000

On Mar 25, 2014, at 12:22 AM, Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:

Acee

Cheers,
Jeff

Hi,

Thanks and Regards

Ines

Adrian

Acee,

Regards,
Alia

Thanks,
Acee

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 25 Mar 2014 09:14:53 -0400

Loa:

I agree that this presentation was very helpful.  I have used it to review
IDR document. 

Sue 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, March 25, 2014 6:04 AM
To: Acee Lindem; Jeff Tantsura
Cc: Adrian Farrel; Ines Robles; Alia Atlas; [email-masked];
[email-masked]

Acee,

a better idea than doing it once in ever wg. I also like the initiative from
Andy to send out the link to Adrians slides:

/Loa.

On 2014-03-25 10:44, Acee Lindem wrote:
>
> On Mar 25, 2014, at 12:22 AM, Jeff Tantsura 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> <mailto:[email-masked]>>, <[email-masked] 
>> <mailto:[email-masked]>>, <[email-masked] 
>> <mailto:[email-masked]>>,
>> <mailto:[email-masked]>>, Jeff Tantsura 
>> <[email-masked] <mailto:[email-masked]>>, 
>> <[email-masked] <mailto:[email-masked]>>, <[email-masked] 
>>> About this: "What is making life hard for document authors?"
>>>
>>> Maybe, one problem is that the authors don't know all the steps, 
>>> that a document goes through during the process of publication, of 
>>> course it is responsibility of the authors read the required 
>>> information to learn about it; This is the minimum thing, that an 
>>> author must do, if he/she wants to publish a document in the IETF.
>>>
>>>> to handle that.____ __ __ However, we are talking like engineers 
>>>> :-)____ Might be nice to focus back on the questions of what is a 
>>>> problem for getting work done. We can come back to how to fix 
>>>> it.____ __ __ Now, all of you complaining that the problem needs to 
>>>> be defined...____ ...please define the problem :-)____ __ __ 
>>>> Adrian____ __ __ *From:*Alia Atlas [mailto:[email-masked] 
>>>> <mailto:[email-masked]>]
>>>> *Subject:* Re: [RTG-DIR] Routing Area Health Check____ __ __ 
>>>> Acee,____ __ __ None of those different directions seems to me to 
>>>> be bad.____ The question was deliberately ask unframed and 
>>>> undefined.____ Adrian and I will define and frame it more - but 
>>>> first we wanted ____ to hear the unframed but thoughtful 
>>>> discussion.____ __ __ Providing reasoning does help everyone 
>>>> determine if they are____ on the same page.____ __ __ Regards,____ 
>>>> Alia____
>>>>
>>>> __ __
>>>>
>>>> <[email-masked] <mailto:[email-masked]>> 
>>>> wrote:____ I agree with Loa that the problem needs to be defined - 
>>>> this discussion has already diverged into 4 different directions.
>>>>
>>>> Thanks,
>>>> Acee____
>>>>
>>>>
>>>> >>> Sent: Friday, March 21, 2014 11:31 AM  To:[email-masked] 
>>>> >>> The crunch question for us is "What makes it hard to get work 
>>>> >>>done in the  Routing Area?" What gets in the way of your work? 
>>>> >>>What is making life hard  for document authors? How could 
>>>> >>>working groups be doing better? We are  open to all and every 
>>>> >>>type of answer. We are happy to have quick, one-line  answers or 
>>>> >>> PS Please respond to both aliases because not everyone is on 
>>>> >>>both lists. Sorry  that that means some of you will get 
>>>> >>>duplicates.
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >
>>>> >--
>>>> >
>>>> >

--

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 25 Mar 2014 13:45:24 +0000

Acee, and all,
This is a very good presentation indeed.

I just wonder whether statistics from some other WGs is not needed for this - the current presentation actually calls for that in Slide 4...

And, IMHO and FWIW, the most important point is raised on Slide 14. Once upon a time existing implementation (= running code) has been a mandatory requirement for the Standards Track documents in the Routing Area. This requirement has been relaxed - but my gut feeling is that restoration of this rule would really help in getting the job done better  and faster.

My 2c,
       Sasha
Email: [email-masked]
Mobile: 054-9266302

From: rtg-dir [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: Tuesday, March 25, 2014 11:44 AM
To: Jeff Tantsura
Cc: Adrian Farrel; Ines Robles; Alia Atlas; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] Routing Area Health Check

Acee

Cheers,
Jeff

Hi,

Maybe, one problem is that the authors don't know all the steps, that a document goes through during the process of publication, of course it is responsibility of the authors read the required information to learn about it; This is the minimum thing, that an author must do, if he/she wants to publish a document in the IETF.

Thanks and Regards

Ines

Adrian

Acee,

Regards,
Alia

Thanks,
Acee

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 25 Mar 2014 15:38:37 +0100

Hello ADs, Directorate, Chairs,

Interesting questions, thanks for caring and asking. 

I am probably going to cut my answer into separate independent mails, as there are vastly different topics in this question.

First, as a member of the RTG Directorate, I actually feel a little "under-utilized". An occasional review of an I-D at an extremely late state of its process, and a very rare more global question like this. As has been discussed widely lately, ADs are overworked and have too little time, so perhaps they do not call on the directorate enough - and, also, delegation of tasks that the ADs have to do is probably perceived as rather hard.

I've been dumbfounded by some of the reviews I have seen from ADs, either during AD Evaluation or IESG Reviews: one particular case came to mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't matter what document or WG it was, what matters is that (i) it doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, (iii) there wasn't really something in the DISCUSS/COMMENTs that required the wizardry of a yellow dot (just some routing background), and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the document authors...its late, design decisions have been made, which are being questioned, etc....it tires people out, pisses off authors, and frustrates everybody involved.

So, I've been playing around with a couple of ideas on the sideline, unofficially, and with only unwitting assistance from others involved....

Thought #1:
I-Ds - when called for adoption as WG documents, or when published as draft-ietf-...-00's, gets someone from the directorate assigned, to provide an initial review and thoughts on "what directions would be good to take (or avoid) here". That same reviewer can, occasionally, be invoked by the WG chairs or authors, in the "so, did we catch this right?" -- and, of course, should be called in on the WGLC of the document. I think of it a little as the "area advisors" but to a document rather than a WG as a whole. 

I've been playing around with that a bit, as an author: 

	o	Since I know very little about security, I've looped in somebody who did, when 
		having published a -00, and again the same person as needed later in the process.
		I've gotten  hugely valuable feedback - making the ultimate SEC-DIR and SEC-AD 
		reviews a lot  less painful for me (and, given how little I knew about security, presumably 
		less  frustrating/time-consuming for the ADs, too, than if I had been just shooting blind).

	o	Since I know even less about OPS stuff, Adrian looped an OPS guy in on an
		individual -01, who asked a lot of good questions to what we were doing, and why,
		and which is hugely helpful.

As an author in the RTG Area, the SEC and OPS ADs are often real "roadblocks". Reasonably so, of course, they represent important concerns. And gosh, every time I encounter any AD, I have to explain the whole context over once again since, even if they've already gotten the story once, they have to follow sufficiently many documents and topics that something is bound to be flushed from their cache.

Having someone, from the respective directorate, be more of a facilitator, sparring-partner, and who - over time - follows the document (and, presumably, follows much fewer documents concurrently) through the process with the authors would be great, as an author. And possibly makes the ADs encounter less poor documents.

I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS folks, and I have no reason to not expect Alia to have the same high (or higher) standards....so I imagine that a way the RTG-DIR could help "improve the image of the ADs" and at the same time get the ADs time liberated from writing 10-page discusses, would be something like the above....

In short, what I envision is a structured way of getting:
	o	very early-reviews
	o	a semi-permanent attachment of a reviewer from the directorateS to a document
	o	this, through the documents lifecycle.

Not sure if it scales, either, but as an author I've greatly enjoyed having such a "ongoing relationship" with people helping me avoid pitfalls.

A final note: having been around for a while in the IETF, it is really easy to ask around for help from among other IETFers that one knows -- then again, having been around for a while, presumably one has more experience and needs less help in avoiding pitfalls. For a new(ish) author, who knows few people and who presumably might be likely to need more help in avoiding said pitfalls, it's a lot harder to actually reach out and get the right people's eyes on a document -- and, even to know what eyes are good to get on it.

This might, actually, therefore be also a good way of the IETF to be more welcoming and inclusive to new folks wanting to get involved.

Thought #2:
So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter version of thought #1 is to have a more structure directorate review cycle during IETF LC, or perhaps during "Publication Requested" and before "AD Evaluation". I am thinking that these be of the form: an I-D hits the AD, the responsible/sponsoring AD requests directorate reviews from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and reviewer iterate until either (i) issues are squared off or (ii) either authors or reviewer declare the other as "bat-crap-crazy" (or, complains that the other side is not responsive) and raise the issue to the AD. AD moves the document forward to "AD Evaluation" only once happy with the outcome of directorate reviews. In short, hiving out a lot more of the "problem fixing" that happens during these reviews off to the directorates - and leaving ADs to process presumably "less broken" documents.

As an author, I have actually found it a LOT easier/faster to iterate with a directorate reviewer (who has my document fresh in mind), than with an AD who's preoccupied with a dozen or so documents at the same time, and other emergencies. Now, mind you, some ADs are good at saying "Busy, will come back to you in n days" -- others, alas, do "play dead" if they feel they have more important fish to fry, and that's frustrating.

This might lessen the load on the ADs, but still has the disadvantage that one gets feedback *very* late in the process....just a little bit earlier than during IESG processing.

Thought #3:
I thought it's worth calling out, that either of the above are not really related to RTG documents: I should think that RTG WG Chairs are plenty able to do the necessary during WG processing, and as an author in the RTG Area, I do usually know how to grab someone competent from the same area for advice, as needed. While doing something like this intra-area can be a good thing, the real boast that I, as document author, have felt has been through getting cross-area feedback. Just as (being forced to be) reviewing document outside of the RTG area has been hugely educational and.

Cheers,

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 25 Mar 2014 15:57:05 +0100

On 25 Mar 2014, at 14:45, Alexander Vainshtein <[email-masked]> wrote:

> I just wonder whether statistics from some other WGs is not needed for this – the current presentation actually calls for that in Slide 4…
>  
> And, IMHO and FWIW, the most important point is raised on Slide 14. Once upon a time existing implementation (= running code) has been a mandatory requirement for the Standards Track documents in the Routing Area. This requirement has been relaxed – but my gut feeling is that restoration of this rule would really help in getting the job done better  and faster.

"Rough consensus and Running code" - very much so. I understand why the requirement has been relaxed, and why it being a "rule" might be too rigid.

But I do believe that several blunders over the past years could have been averted, had there been *running* code before standards.

Thomas

> On Mar 25, 2014, at 12:22 AM, Jeff Tantsura <[email-masked]> wrote:
> 
> 
> From: Ines Robles <[email-masked]>
> To: Adrian Farrel <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Alia Atlas <[email-masked]>
> Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "[email-masked]" <[email-masked]>, Joel Halpern <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Thomas Morin <[email-masked]>, Martin Vigoureux <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Loa Andersson <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Acee Lindem Lindem III <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Alvaro Retana <[email-masked]>, Jeff Tantsura <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Alvaro Retana <[email-masked]>, <[email-masked]>, Alia Atlas <[email-masked]>, <[email-masked]>
>  
> Hi,
> 
> 
> Cc: Loa Andersson; John E Drake; [email-masked]; [email-masked]; [email-masked]; Alia Atlas

---

From: Alia Atlas <[email-masked]>
Date: Tue, 25 Mar 2014 10:58:34 -0400

Thomas,

Thanks very much for your thoughts.  On the being underutilized and on
cross-area review, what do you and others in the Routing Directorate think
about being asked to follow a single additional working group that is not
in RTG and may have routing related issues?

For the time speedup of ADs, I'm told that it'd be really really useful to
have more active document shepherds - who can facilitate getting comments
and having them addressed.  I'm not sure how to put that into place really.
 As a WG chair, I felt like I was processing and pushing few enough drafts
that I could do the shepherd job also - but I know that there are some WGs
where there is higher throughput.  It's also a good way of growing a
person, to let them see the whole process and deal with the discussions.

For the drafts, I'd love to see earlier reviews.  I'm not sure if at WG
adoption is quite the right time, but it is a good approximation of "early
in the process".   We could ask WG chairs to request a reviewer at that
point for drafts that may need it and see what the load looks like.  For a
start-up, having interested WG chairs identify WG drafts that could benefit
from review would be helpful/interesting in terms of seeing the workload.

Regards,
Alia

On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen
<[email-masked]>wrote:

> I am probably going to cut my answer into separate independent mails, as
> there are vastly different topics in this question.
>
> First, as a member of the RTG Directorate, I actually feel a little
> "under-utilized". An occasional review of an I-D at an extremely late state
> of its process, and a very rare more global question like this. As has been
> discussed widely lately, ADs are overworked and have too little time, so
> perhaps they do not call on the directorate enough - and, also, delegation
> of tasks that the ADs have to do is probably perceived as rather hard.
>
> I've been dumbfounded by some of the reviews I have seen from ADs, either
> during AD Evaluation or IESG Reviews: one particular case came to mind
> where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker
> during IESG Evaluation. It doesn't matter what document or WG it was, what
> matters is that (i) it doesn't scale IETF-wide, (ii) it's poor use of
> Adrian's time, (iii) there wasn't really something in the DISCUSS/COMMENTs
> that required the wizardry of a yellow dot (just some routing background),
> and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during
> IESG Evaluation really isn't helpful to the document authors...its late,
> design decisions have been made, which are being questioned, etc....it
> tires people out, pisses off authors, and frustrates everybody involved.
>
> So, I've been playing around with a couple of ideas on the sideline,
> unofficially, and with only unwitting assistance from others involved....
>
> Thought #1:
> I-Ds - when called for adoption as WG documents, or when published as
> draft-ietf-...-00's, gets someone from the directorate assigned, to provide
> an initial review and thoughts on "what directions would be good to take
> (or avoid) here". That same reviewer can, occasionally, be invoked by the
> WG chairs or authors, in the "so, did we catch this right?" -- and, of
> course, should be called in on the WGLC of the document. I think of it a
> little as the "area advisors" but to a document rather than a WG as a whole.
>
> As an author in the RTG Area, the SEC and OPS ADs are often real
> "roadblocks". Reasonably so, of course, they represent important concerns.
> And gosh, every time I encounter any AD, I have to explain the whole
> context over once again since, even if they've already gotten the story
> once, they have to follow sufficiently many documents and topics that
> something is bound to be flushed from their cache.
>
> Having someone, from the respective directorate, be more of a facilitator,
> sparring-partner, and who - over time - follows the document (and,
> presumably, follows much fewer documents concurrently) through the process
> with the authors would be great, as an author. And possibly makes the ADs
> encounter less poor documents.
>
> I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) be
> just as much of a roadblock as the SEC/OPS folks, and I have no reason to
> not expect Alia to have the same high (or higher) standards....so I imagine
> that a way the RTG-DIR could help "improve the image of the ADs" and at the
> same time get the ADs time liberated from writing 10-page discusses, would
> be something like the above....
>
> Not sure if it scales, either, but as an author I've greatly enjoyed
> having such a "ongoing relationship" with people helping me avoid pitfalls.
>
> A final note: having been around for a while in the IETF, it is really
> easy to ask around for help from among other IETFers that one knows -- then
> again, having been around for a while, presumably one has more experience
> and needs less help in avoiding pitfalls. For a new(ish) author, who knows
> few people and who presumably might be likely to need more help in avoiding
> said pitfalls, it's a lot harder to actually reach out and get the right
> people's eyes on a document -- and, even to know what eyes are good to get
> on it.
>
> This might, actually, therefore be also a good way of the IETF to be more
> welcoming and inclusive to new folks wanting to get involved.
>
> Thought #2:
> So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter version
> of thought #1 is to have a more structure directorate review cycle during
> IETF LC, or perhaps during "Publication Requested" and before "AD
> Evaluation". I am thinking that these be of the form: an I-D hits the AD,
> the responsible/sponsoring AD requests directorate reviews from all the
> concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and reviewer
> iterate until either (i) issues are squared off or (ii) either authors or
> reviewer declare the other as "bat-crap-crazy" (or, complains that the
> other side is not responsive) and raise the issue to the AD. AD moves the
> document forward to "AD Evaluation" only once happy with the outcome of
> directorate reviews. In short, hiving out a lot more of the "problem
> fixing" that happens during these reviews off to the directorates - and
> leaving ADs to process presumably "less broken" documents.
>
> As an author, I have actually found it a LOT easier/faster to iterate with
> a directorate reviewer (who has my document fresh in mind), than with an AD
> who's preoccupied with a dozen or so documents at the same time, and other
> emergencies. Now, mind you, some ADs are good at saying "Busy, will come
> back to you in n days" -- others, alas, do "play dead" if they feel they
> have more important fish to fry, and that's frustrating.
>
> This might lessen the load on the ADs, but still has the disadvantage that
> one gets feedback *very* late in the process....just a little bit earlier
> than during IESG processing.
>
> Thought #3:
> I thought it's worth calling out, that either of the above are not really
> related to RTG documents: I should think that RTG WG Chairs are plenty able
> to do the necessary during WG processing, and as an author in the RTG Area,
> I do usually know how to grab someone competent from the same area for
> advice, as needed. While doing something like this intra-area can be a good
> thing, the real boast that I, as document author, have felt has been
> through getting cross-area feedback. Just as (being forced to be) reviewing
> document outside of the RTG area has been hugely educational and.
>
> Cheers,
>
> Thomas
>
>

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 25 Mar 2014 16:09:41 +0100

Alia,

On 25 Mar 2014, at 15:58, Alia Atlas <[email-masked]> wrote:

> Thomas,
> 
> Thanks very much for your thoughts.  On the being underutilized and on cross-area review, what do you and others in the Routing Directorate think about being asked to follow a single additional working group that is not in RTG and may have routing related issues?

Can't speak for the others, but I'd be glad to, personally.

> 
> For the time speedup of ADs, I'm told that it'd be really really useful to have more active document shepherds - who can facilitate getting comments and having them addressed.  I'm not sure how to put that into place really.  As a WG chair, I felt like I was processing and pushing few enough drafts that I could do the shepherd job also - but I know that there are some WGs where there is higher throughput.  It's also a good way of growing a person, to let them see the whole process and deal with the discussions.

That is a good point. Honestly, I do not know, and am really torn on this issue.

On one hand, sometimes having a shepherd as "go-between" to whip lazy ADs ;) or reviewers to come back with "So, did this address your concerns?" could perhaps be helpful. Oftentimes, however - and this is the "have been in this for long enough to have many of the ADs on Jabber by now" - the shepherd is just-another-go-in-the-way: popping an IM to Adrian (or whoever), getting a resolution, moving on, is a faster way of waking him up from hibernation than waiting for a third-party to do the same. Same for an AD holding a discuss, adding an extra intermediary to go through ....not sold on the idea.

So, I really do not know what to think about this. In the rare cases where I have needed some whipping that I couldn't do myself, it has been an AD so non-responsive that I doubt that a shepherd would do (was a long time ago) and it required several other ADs ganging up....or (more recently) where there was an issue with IANA requiring resolution (Adrian helped out there, but possibly somebody else could have, too).

> For the drafts, I'd love to see earlier reviews.  I'm not sure if at WG adoption is quite the right time, but it is a good approximation of "early in the process".  

I agree. It was just the least-arbitrary version number I could come up with on short notice ;)

> We could ask WG chairs to request a reviewer at that point for drafts that may need it and see what the load looks like.  For a start-up, having interested WG chairs identify WG drafts that could benefit from review would be helpful/interesting in terms of seeing the workload.

Can't disagree on this.

Thomas

> 
> Regards,
> Alia
> 
> 
> On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen <[email-masked]> wrote:

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 25 Mar 2014 15:20:23 +0000

Hi, Alia,

On Mar 25, 2014, at 10:58 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Thomas,

I think this is a great idea and a best practice. Something of a "liaison" to key WGs that could have routing-related issues. It can help with early identification of issues and raise appropriate flags, but also it can be input into the early review queue (point you also make below).

Thanks,

-- Carlos.

For the drafts, I'd love to see earlier reviews.  I'm not sure if at WG adoption is quite the right time, but it is a good approximation of "early in the process".   We could ask WG chairs to request a reviewer at that point for drafts that may need it and see what the load looks like.  For a start-up, having interested WG chairs identify WG drafts that could benefit from review would be helpful/interesting in terms of seeing the workload.

Regards,
Alia

On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:
Hello ADs, Directorate, Chairs,

Thought #1:

Thought #2:

Thought #3:

Cheers,

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 25 Mar 2014 16:21:42 +0100

Hello ADs, Directorate and Chairs,

Oh, and one more thing.....I know, I live a sad life when I realise that I socialise with IETFers over the weekend, and this email became the topic of conversation....but, hey...

This mail thread started out with some folks making proposals on closing, merging, and moving WGs, which I briefly mentioned as a discussion-point during the aforementioned conversation - thought I'd bring the resulting discussion out here.

The exchange (sanitised for public consumption by removing swear-words) went roughly like this:

	Me:	So the RTG ADs asked for a "health check" of the RTG Area, to the RTG-WG chairs and RTG-DIR, what 
		could be done to better the area, make it more efficient, etc.

	Me:	Someone suggested that the best was to close <list-of-wg's> and merge <other-list-of-wg's>, and perhaps

	IETFer #1 (who has been in the IETF for 5-6 years) interrupted:
		That's  the F***ING problem with the IETF, all discussions happen behind closed doors, and we
		do not have a say in things.

	IETFer #2 (who's been having an on-again-off-again relationship with the IETF for a decade or so):
		That's the same with all those secret directorates, whose reviews we now have to contend with, where
		did they suddenly come from, secret committees.

	<rant went on for a bit, then we veered into much more consensual subjects, like the 
	  the existence of extraterrestrials, if mint-jelly really belongs in a hot meal, if 
	  vegemite qualifies as food,and who should win this years premier league in football>

I am not sure that this is RTG-area specific, but it is not the first time that I have heard someone do a double-take when presented with a GEN-ART, SEC-DIR, or other such review, or heard of discussions within such groups, or the existence of such groups. 

Perhaps a root cause of this is, that these groups are seen (like the IESG) as "roadblocks, not facilitators" because...getting a huge critical review during an IETF LC is just that...a roadblock. And, perhaps, getting the directorates more involved much earlier would also solve such "image problems" of the IETF being an "old-folks-club"?

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 25 Mar 2014 16:44:41 +0100

Hello ADs, Directorate, and Chairs,

I promise, this is going to be my last mail on this for a bit - it's the last "topic" that I believe I have queued up in my mind that needs to get out.

I think that WG chairs have a hard job: they need to facilitate progress, advance the work-items, satisfy the milestones and pressure from the ADs wanting progress -- and, at the same time -- remain carefully impartial. 

Essentially, we want "interested, but disinterested" chairs -- with enough of stakes in the race to invest the necessary time to see progress, but who do not have any stakes causing them to favour one solution/architecture/approach over another. We have some "guidelines" to this effect (chair-author separation), but this balance has turned out to remarkably difficult to get right -- and, we have seen things go haywire by swinging to either side, in the recent and not-so-recent past.

Making this difficult trade-off work may require more active involvement by the ADs to ensure that chairs recuse when they need to, and step aside if they become part of the problem. That is not an easy thing to ask the chairs, who don't have an easy job in some of the working groups, so the ADs -- in my view -- need to take a more proactive role in managing the chairs, being alert to potential problems, and affecting timely corrective actions.

Of course, "managing their WG chairs" are already in the job-description of the ADs, and doing so (well) takes effort and time. 

Hence, as indicated previously, we should see if we can find a way of easing some of the load on our ADs so that they have that necessary time available.

Best,

Thomas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 Mar 2014 13:46:34 -0400

I am a little concerned that assigned directorate members to working 
groups will produce negative effects:
1) It will lead to more scheduling conflict.
2) It will lead to an assumption that this one person will review all 
the output of a given WG.  I think we are actually better off if that 
task sometimes moves, as it ensures that fresh eyes are looking, for 
example to detect that assumptions are actually stated rather than 
merely in the minds of the WG.

Yours,
Joel

On 3/25/14, 10:58 AM, Alia Atlas wrote:
> cross-area review, what do you and others in the Routing Directorate
> think about being asked to follow a single additional working group that
> is not in RTG and may have routing related issues?
>
> For the time speedup of ADs, I'm told that it'd be really really useful
> to have more active document shepherds - who can facilitate getting
> comments and having them addressed.  I'm not sure how to put that into
> place really.  As a WG chair, I felt like I was processing and pushing
> few enough drafts that I could do the shepherd job also - but I know
> that there are some WGs where there is higher throughput.  It's also a
> good way of growing a person, to let them see the whole process and deal
> with the discussions.
>
> adoption is quite the right time, but it is a good approximation of
> "early in the process".   We could ask WG chairs to request a reviewer
> at that point for drafts that may need it and see what the load looks
> like.  For a start-up, having interested WG chairs identify WG drafts
> that could benefit from review would be helpful/interesting in terms of
> seeing the workload.
>
> Regards,
> Alia
>
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I am probably going to cut my answer into separate independent
>     mails, as there are vastly different topics in this question.
>
>     "under-utilized". An occasional review of an I-D at an extremely
>     late state of its process, and a very rare more global question like
>     this. As has been discussed widely lately, ADs are overworked and
>     have too little time, so perhaps they do not call on the directorate
>     enough - and, also, delegation of tasks that the ADs have to do is
>     probably perceived as rather hard.
>
>     I've been dumbfounded by some of the reviews I have seen from ADs,
>     either during AD Evaluation or IESG Reviews: one particular case
>     came to mind where Adrian sent what looked like a 10-page
>     DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't
>     matter what document or WG it was, what matters is that (i) it
>     doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, (iii)
>     there wasn't really something in the DISCUSS/COMMENTs that required
>     the wizardry of a yellow dot (just some routing background), and --
>     most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during
>     IESG Evaluation really isn't helpful to the document authors...its
>     late, design decisions have been made, which are being questioned,
>     etc....it tires people out, pisses off authors, and frustrates
>     everybody involved.
>
>     I-Ds - when called for adoption as WG documents, or when published
>     as draft-ietf-...-00's, gets someone from the directorate assigned,
>     to provide an initial review and thoughts on "what directions would
>     be good to take (or avoid) here". That same reviewer can,
>     occasionally, be invoked by the WG chairs or authors, in the "so,
>     did we catch this right?" -- and, of course, should be called in on
>     the WGLC of the document. I think of it a little as the "area
>     advisors" but to a document rather than a WG as a whole.
>
>     "roadblocks". Reasonably so, of course, they represent important
>     concerns. And gosh, every time I encounter any AD, I have to explain
>     the whole context over once again since, even if they've already
>     gotten the story once, they have to follow sufficiently many
>     documents and topics that something is bound to be flushed from
>     their cache.
>
>     Having someone, from the respective directorate, be more of a
>     facilitator, sparring-partner, and who - over time - follows the
>     document (and, presumably, follows much fewer documents
>     concurrently) through the process with the authors would be great,
>     as an author. And possibly makes the ADs encounter less poor documents.
>
>     I know that Adrian can (cf. the aforementioned 10-page
>     DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS
>     folks, and I have no reason to not expect Alia to have the same high
>     (or higher) standards....so I imagine that a way the RTG-DIR could
>     help "improve the image of the ADs" and at the same time get the ADs
>     time liberated from writing 10-page discusses, would be something
>     like the above....
>
>     A final note: having been around for a while in the IETF, it is
>     really easy to ask around for help from among other IETFers that one
>     knows -- then again, having been around for a while, presumably one
>     has more experience and needs less help in avoiding pitfalls. For a
>     new(ish) author, who knows few people and who presumably might be
>     likely to need more help in avoiding said pitfalls, it's a lot
>     harder to actually reach out and get the right people's eyes on a
>     document -- and, even to know what eyes are good to get on it.
>
>     This might, actually, therefore be also a good way of the IETF to be
>     more welcoming and inclusive to new folks wanting to get involved.
>
>     Thought #2:
>     So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter
>     version of thought #1 is to have a more structure directorate review
>     cycle during IETF LC, or perhaps during "Publication Requested" and
>     before "AD Evaluation". I am thinking that these be of the form: an
>     I-D hits the AD, the responsible/sponsoring AD requests directorate
>     reviews from all the concerned directorates (GEN, SEC, OPS, RTG,
>     TSP, ...). Authors and reviewer iterate until either (i) issues are
>     squared off or (ii) either authors or reviewer declare the other as
>     "bat-crap-crazy" (or, complains that the other side is not
>     responsive) and raise the issue to the AD. AD moves the document
>     forward to "AD Evaluation" only once happy with the outcome of
>     fixing" that happens during these reviews off to the directorates -
>     and leaving ADs to process presumably "less broken" documents.
>
>     As an author, I have actually found it a LOT easier/faster to
>     iterate with a directorate reviewer (who has my document fresh in
>     mind), than with an AD who's preoccupied with a dozen or so
>     documents at the same time, and other emergencies. Now, mind you,
>     some ADs are good at saying "Busy, will come back to you in n days"
>     -- others, alas, do "play dead" if they feel they have more
>     important fish to fry, and that's frustrating.
>
>     This might lessen the load on the ADs, but still has the
>     disadvantage that one gets feedback *very* late in the
>     process....just a little bit earlier than during IESG processing.
>
>     Thought #3:
>     I thought it's worth calling out, that either of the above are not
>     really related to RTG documents: I should think that RTG WG Chairs
>     are plenty able to do the necessary during WG processing, and as an
>     author in the RTG Area, I do usually know how to grab someone
>     competent from the same area for advice, as needed. While doing
>     something like this intra-area can be a good thing, the real boast
>     that I, as document author, have felt has been through getting
>     cross-area feedback. Just as (being forced to be) reviewing document
>     outside of the RTG area has been hugely educational and.
>
>     Cheers,
>
>     Thomas
>
>
>     done in the

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Mar 2014 17:48:31 +0000

Thomas

If it were not for those directorates the work of some of the ADs would
go from difficult to impossible. Remember that whilst a RTG AD can skim
a draft and say - "nothing that effects the routing system here - no 
objection",
the OPS, SEC and GEN ADs need to look at pretty much everything in detail.

Stewart

On 25/03/2014 15:21, Thomas Clausen wrote:
> Oh, and one more thing.....I know, I live a sad life when I realise 
> that I socialise with IETFers over the weekend, and this email became 
> the topic of conversation....but, hey...
>
> This mail thread started out with some folks making proposals on 
> closing, merging, and moving WGs, which I briefly mentioned as a 
> discussion-point during the aforementioned conversation - thought I'd 
> bring the resulting discussion out here.
>
> Me:So the RTG ADs asked for a "health check" of the RTG Area, to the 
> RTG-WG chairs and RTG-DIR, what
> Me:Someone suggested that the best was to close <list-of-wg's> and 
> merge <other-list-of-wg's>, and perhaps
>
> I am not sure that this is RTG-area specific, but it is not the first 
> time that I have heard someone do a double-take when presented with a 
> GEN-ART, SEC-DIR, or other such review, or heard of discussions within 
> such groups, or the existence of such groups.
>
> Perhaps a root cause of this is, that these groups are seen (like the 
> IESG) as "roadblocks, not facilitators" because...getting a huge 
> critical review during an IETF LC is just that...a roadblock. And, 
> perhaps, getting the directorates more involved much earlier would 
> also solve such "image problems" of the IETF being an "old-folks-club"?
>
> Thomas
>
>
> On 25 Mar 2014, at 15:58, Alia Atlas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Thomas,
>>
>> Thanks very much for your thoughts.  On the being underutilized and 
>> on cross-area review, what do you and others in the Routing 
>> Directorate think about being asked to follow a single additional 
>> working group that is not in RTG and may have routing related issues?
>>
>> For the time speedup of ADs, I'm told that it'd be really really 
>> useful to have more active document shepherds - who can facilitate 
>> getting comments and having them addressed.  I'm not sure how to put 
>> that into place really.  As a WG chair, I felt like I was processing 
>> and pushing few enough drafts that I could do the shepherd job also - 
>> but I know that there are some WGs where there is higher throughput. 
>>  It's also a good way of growing a person, to let them see the whole 
>> process and deal with the discussions.
>>
>> For the drafts, I'd love to see earlier reviews.  I'm not sure if at 
>> WG adoption is quite the right time, but it is a good approximation 
>> of "early in the process".   We could ask WG chairs to request a 
>> reviewer at that point for drafts that may need it and see what the 
>> load looks like.  For a start-up, having interested WG chairs 
>> identify WG drafts that could benefit from review would be 
>> helpful/interesting in terms of seeing the workload.
>>
>> Regards,
>> Alia
>>
>>
>>     First, as a member of the RTG Directorate, I actually feel a
>>     little "under-utilized". An occasional review of an I-D at an
>>     extremely late state of its process, and a very rare more global
>>     question like this. As has been discussed widely lately, ADs are
>>     overworked and have too little time, so perhaps they do not call
>>     on the directorate enough - and, also, delegation of tasks that
>>     the ADs have to do is probably perceived as rather hard.
>>
>>     I've been dumbfounded by some of the reviews I have seen from
>>     ADs, either during AD Evaluation or IESG Reviews: one particular
>>     case came to mind where Adrian sent what looked like a 10-page
>>     doesn't scale IETF-wide, (ii) it's poor use of Adrian's time,
>>     (iii) there wasn't really something in the DISCUSS/COMMENTs that
>>     required the wizardry of a yellow dot (just some routing
>>     background), and -- most importantly -- (iv) getting a 10-page
>>     DISCUSS/COMMENT during IESG Evaluation really isn't helpful to
>>     the document authors...its late, design decisions have been made,
>>     which are being questioned, etc....it tires people out, pisses
>>     off authors, and frustrates everybody involved.
>>
>>     So, I've been playing around with a couple of ideas on the
>>     sideline, unofficially, and with only unwitting assistance from
>>     others involved....
>>
>>     Thought #1:
>>     I-Ds - when called for adoption as WG documents, or when
>>     published as draft-ietf-...-00's, gets someone from the
>>     directorate assigned, to provide an initial review and thoughts
>>     on "what directions would be good to take (or avoid) here". That
>>     same reviewer can, occasionally, be invoked by the WG chairs or
>>     authors, in the "so, did we catch this right?" -- and, of course,
>>     should be called in on the WGLC of the document. I think of it a
>>                     reviews a lot  less painful for me (and, given
>>     how little I knew about security, presumably
>>                     less  frustrating/time-consuming for the ADs,
>>     too, than if I had been just shooting blind).
>>
>>     concerns. And gosh, every time I encounter any AD, I have to
>>     explain the whole context over once again since, even if they've
>>     already gotten the story once, they have to follow sufficiently
>>     many documents and topics that something is bound to be flushed
>>     from their cache.
>>
>>     concurrently) through the process with the authors would be
>>     great, as an author. And possibly makes the ADs encounter less
>>     poor documents.
>>
>>     folks, and I have no reason to not expect Alia to have the same
>>     high (or higher) standards....so I imagine that a way the RTG-DIR
>>     could help "improve the image of the ADs" and at the same time
>>     get the ADs time liberated from writing 10-page discusses, would
>>     Not sure if it scales, either, but as an author I've greatly
>>     enjoyed having such a "ongoing relationship" with people helping
>>     me avoid pitfalls.
>>
>>     really easy to ask around for help from among other IETFers that
>>     one knows -- then again, having been around for a while,
>>     presumably one has more experience and needs less help in
>>     avoiding pitfalls. For a new(ish) author, who knows few people
>>     and who presumably might be likely to need more help in avoiding
>>     said pitfalls, it's a lot harder to actually reach out and get
>>     the right people's eyes on a document -- and, even to know what
>>     eyes are good to get on it.
>>
>>     This might, actually, therefore be also a good way of the IETF to
>>     be more welcoming and inclusive to new folks wanting to get involved.
>>
>>     Thought #2:
>>     So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps,
>>     lighter version of thought #1 is to have a more structure
>>     directorate review cycle during IETF LC, or perhaps during
>>     "Publication Requested" and before "AD Evaluation". I am thinking
>>     that these be of the form: an I-D hits the AD, the
>>     responsible/sponsoring AD requests directorate reviews from all
>>     the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...).
>>     Authors and reviewer iterate until either (i) issues are squared
>>     off or (ii) either authors or reviewer declare the other as
>>     directorate reviews. In short, hiving out a lot more of the
>>     "problem fixing" that happens during these reviews off to the
>>     directorates - and leaving ADs to process presumably "less
>>     broken" documents.
>>
>>     some ADs are good at saying "Busy, will come back to you in n
>>     days" -- others, alas, do "play dead" if they feel they have more
>>     I thought it's worth calling out, that either of the above are
>>     not really related to RTG documents: I should think that RTG WG
>>     Chairs are plenty able to do the necessary during WG processing,
>>     and as an author in the RTG Area, I do usually know how to grab
>>     someone competent from the same area for advice, as needed. While
>>     doing something like this intra-area can be a good thing, the
>>     real boast that I, as document author, have felt has been through
>>     getting cross-area feedback. Just as (being forced to be)
>>     reviewing document outside of the RTG area has been hugely
>>     educational and.
>>
>>     Cheers,
>>
>>     Thomas
>>
>>
>>     both lists. Sorry

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 25 Mar 2014 18:51:03 +0100

Stewart,

Please don't shoot the messenger. 

I've grown to love GEN-ART and SEC-DIR and friends -- having had some darn good people review my docs has helped.

I was relaying what I'd seen/heard other people express, and figured that these entities had an image-problem, rather easy to solve.

And yes, you're very very right, the role of a SEC-DIR review is very very different.....

Thomas

On 25 Mar 2014, at 18:48, Stewart Bryant <[email-masked]> wrote:

> a draft and say - "nothing that effects the routing system here - no objection",

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Mar 2014 13:57:06 -0400

> from review would be helpful/interesting in terms of seeing the workload.

If we *really* have reviewers who'll do language level reviews, it may be
reasonable to request such review prior to WG adoption.  That way the
technical issues will also let language nits be resolved rather than having
to squish language nits very late.

-- Jeff

---

From: Alia Atlas <[email-masked]>
Date: Tue, 25 Mar 2014 15:12:50 -0400

Adrian and I have discussed the need for good early review and follow
through of drafts starting with
WG adoption.  We have also heard that the Routing Directorate could be used
more (though the situation may
vary by individual).

We are writing up the idea of a "Document Mentor".   More details to follow
(plan for next week) once Adrian
and I have agreement on paper for the idea.

As far as English language mentoring, it sounds like George, Loa, and Ross
have a trial run going in MPLS.
We can discuss having common organization for volunteers on each WG's wiki
or on the routing-area wiki.

Thoughts?

Alia

On Tue, Mar 25, 2014 at 11:09 AM, Thomas Clausen
<[email-masked]>wrote:

> On one hand, sometimes having a shepherd as "go-between" to whip lazy ADs
> ;) or reviewers to come back with "So, did this address your concerns?"
> could perhaps be helpful. Oftentimes, however - and this is the "have been
> in this for long enough to have many of the ADs on Jabber by now" - the
> shepherd is just-another-go-in-the-way: popping an IM to Adrian (or
> whoever), getting a resolution, moving on, is a faster way of waking him up
> from hibernation than waiting for a third-party to do the same. Same for an
> AD holding a discuss, adding an extra intermediary to go through ....not
> sold on the idea.
>
> So, I really do not know what to think about this. In the rare cases where
> I have needed some whipping that I couldn't do myself, it has been an AD so
> non-responsive that I doubt that a shepherd would do (was a long time ago)
> and it required several other ADs ganging up....or (more recently) where
> there was an issue with IANA requiring resolution (Adrian helped out there,
> but possibly somebody else could have, too).
>
> in the process".
> We could ask WG chairs to request a reviewer at that point for drafts that
> may need it and see what the load looks like.  For a start-up, having
> interested WG chairs identify WG drafts that could benefit from review
> would be helpful/interesting in terms of seeing the workload.
>
>
> Can't disagree on this.
>
> Thomas
>
>
> Regards,
> Alia
>
>
> On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen <[email-masked]
> > wrote:
>
>> facilitator, sparring-partner, and who - over time - follows the document
>> (and, presumably, follows much fewer documents concurrently) through the
>> process with the authors would be great, as an author. And possibly makes
>> the ADs encounter less poor documents.
>>
>> I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT)
>> be just as much of a roadblock as the SEC/OPS folks, and I have no reason
>> to not expect Alia to have the same high (or higher) standards....so I
>> imagine that a way the RTG-DIR could help "improve the image of the ADs"
>> and at the same time get the ADs time liberated from writing 10-page
>> discusses, would be something like the above....
>>
>> version of thought #1 is to have a more structure directorate review cycle
>> during IETF LC, or perhaps during "Publication Requested" and before "AD
>> As an author, I have actually found it a LOT easier/faster to iterate
>> with a directorate reviewer (who has my document fresh in mind), than with
>> an AD who's preoccupied with a dozen or so documents at the same time, and
>> other emergencies. Now, mind you, some ADs are good at saying "Busy, will
>> come back to you in n days" -- others, alas, do "play dead" if they feel
>> they have more important fish to fry, and that's frustrating.
>>
>> This might lessen the load on the ADs, but still has the disadvantage
>> that one gets feedback *very* late in the process....just a little bit
>> earlier than during IESG processing.
>>
>> Thought #3:

---

From: Lou Berger <[email-masked]>
Date: Tue, 25 Mar 2014 15:22:45 -0400

On 3/25/2014 3:12 PM, Alia Atlas wrote:
> As far as English language mentoring, it sounds like George, Loa, and
> Ross have a trial run going in MPLS.
> We can discuss having common organization for volunteers on each WG's
> wiki or on the routing-area wiki.
>
> Thoughts?
>

I think language review would be *hugely* helpful.  Personally I'd like
it to occur right *after* WG adoption and once again after the authors
declare a document ready for LC (from the technical perspective). 

Lou

---

From: Alia Atlas <[email-masked]>
Date: Tue, 25 Mar 2014 15:28:20 -0400

Hi Thomas,

On Tue, Mar 25, 2014 at 11:21 AM, Thomas Clausen
<[email-masked]>wrote:

> Oh, and one more thing.....I know, I live a sad life when I realise that I
> socialise with IETFers over the weekend, and this email became the topic of
> conversation....but, hey...
>

Not that sad... or maybe this just sounds familiar...

> This mail thread started out with some folks making proposals on closing,
> merging, and moving WGs, which I briefly mentioned as a discussion-point
> during the aforementioned conversation - thought I'd bring the resulting
> discussion out here.
>

*sigh*  A directorate is "just" a group of people whose opinion is trusted
by the ADs and who have agreed to do work to help the area, such as
requested reviews.  As you (of course) well know, anyone can do the reviews.

There are multiple steps to developing a plan.  The WG chairs and rtg-dir
have valuable and diverse perspectives into
the routing area.   Other participants do too - but it can be harder to
have a completely unstructured and yet productive
discussion.   I certainly intend to discuss and ask for feedback and advice
from the area, but at the end of the day, it
is advice.   If your friend has opinions that she/he would like to share,
I'm happy to listen.

> did they suddenly come from, secret committees.

Interestingly, they've been around for at least the last 12+ years.    And,
just like the IETF, IAB, and IESG being "secret" cabals, just because one
doesn't know about them doesn't make them secret.   There is, of course,
the Routing Area wiki (http://wiki.tools.ietf.org/area/rtg/trac/wiki)  and
the Routing Directorate is linked to there as:
https://www.ietf.org/iesg/directorate/routing.html

> I am not sure that this is RTG-area specific, but it is not the first time
> that I have heard someone do a double-take when presented with a GEN-ART,
> SEC-DIR, or other such review, or heard of discussions within such groups,
> or the existence of such groups.
>
> IESG) as "roadblocks, not facilitators" because...getting a huge critical
> review during an IETF LC is just that...a roadblock. And, perhaps, getting
> the directorates more involved much earlier would also solve such "image
> problems" of the IETF being an "old-folks-club"?
>

I think the double-take is because, for a document author, each document
and the process is lovingly hand-crafted.  From the AD perspective, these
reviews are a well known part of the process and we'e trying to figure out
how to churn out better docs with less back-loading.

As for an "old-folks-club", is that over 25, 30, 40, 50?  The IETF does
tend to be reputation-based, but it is possible to come in and do lots of
very good work quickly and gain that reputation.   Any group with people
forms networks of trust and they all look like insider clubs to those not
involved.   I'm not sure how to fix that...

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 25 Mar 2014 15:33:54 -0400

Hi Joel,

As you well know, we've tried doing reviews at IETF last call - and it is
too late to change significantly much.
My thought is by having someone listen in casually on a non-routing WG,
concerns are likely to be identified
much sooner.

> 1) It will lead to more scheduling conflict.

The request isn't to go to the WG, but to listen to the mailing list.  Both
would be good, but scheduling is already hard.

> 2) It will lead to an assumption that this one person will review all the
> output of a given WG.  I think we are actually better off if that task
> sometimes moves, as it ensures that fresh eyes are looking, for example to
> detect that assumptions are actually stated rather than merely in the minds
> of the WG.
>

Ah - goal is to flag drafts that could use an early review and to determine
when routing clue might be usefully injected.
The one person would not be responsible for reviewing all the output of a
given WG.

We have a newly forming WG (
https://datatracker.ietf.org/doc/charter-ietf-dart/) for which such a
person would be very useful.

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 25 Mar 2014 15:37:40 -0400

Lou,

I hear loud and clear that a language review would be helpful.  I agree
that on
WG adoption and when the authors have prepared the draft for LC are good
times
for it.

The question is whether the language reviewers are volunteering for a
particular
WG or whether we should develop a set of language reviewers for the whole
area.

Alia

---

From: Lou Berger <[email-masked]>
Date: Tue, 25 Mar 2014 15:56:37 -0400

Sorry, I thought the answer here was implied in the discussion, i.e.
that we leverage what the MPLS WG (chairs) have started across the
whole  area...

So to revise my position for utmost clarity:

I think a language review process/team for the RTG area, at the very
least, would be *hugely* helpful.

Lou

On 3/25/2014 3:37 PM, Alia Atlas wrote:
> Lou,
>
> I hear loud and clear that a language review would be helpful.  I
> agree that on
> WG adoption and when the authors have prepared the draft for LC are
> good times
> for it.
>
> WG or whether we should develop a set of language reviewers for the
> whole area.
>
> Alia
>
>
> On Tue, Mar 25, 2014 at 3:22 PM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 25 Mar 2014 16:05:53 -0400

Got it.  Let me get the Document Mentor idea written up first.
The language review process/team would be completely new.
If someone else writes up a strawman first pass of it, that'd be
very useful input ;-)

Alia

---

From: Ross Callon <[email-masked]>
Date: Tue, 25 Mar 2014 21:13:09 +0000

I think that these are the right times. 

We could instead schedule the first review just before the call for WG adoption. This might allow the call for WG adoption to be based on a document which is relatively more readable. However, it would need to be purely voluntary since prior to WG adoption the document is "owned" by the authors, and not by the WG. Chairs could optionally for document which seem to particularly need English language review ask the authors whether or not they would like to move the first review to be before rather than after the call for adoption. 

Ross

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, March 25, 2014 3:23 PM
To: Alia Atlas
Cc: Adrian Farrel; Thomas Clausen; Alia Atlas; <[email-masked]>; [email-masked]
Subject: Re: [RTG-DIR] Routing Area Health Check

Lou

---

From: Ross Callon <[email-masked]>
Date: Tue, 25 Mar 2014 21:26:43 +0000

How does this differ from the "routing area advisors" who have occasionally been assigned to WGs in the past? In some cases these routing area advisors were ADs, but in some cases not. In my experience the routing area advisors rarely did much (if anything). 

It has also been unclear (at least to me) what if any authority went with being the routing area advisor to a WG from another area. 

Ross

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, March 25, 2014 1:47 PM
To: Alia Atlas; Thomas Clausen
Cc: Adrian Farrel; [email-masked]; Alia Atlas; <[email-masked]>
Subject: Re: [RTG-DIR] Routing Area Health Check

Yours,
Joel

---

From: Mach Chen <[email-masked]>
Date: Wed, 26 Mar 2014 03:52:03 +0000

Hi all,

IMHO, to make the directorate members to do more reviews in early stage is great idea, maybe we do not need to "officially" assign directorate members to working groups, but just encourage the directorate members to do the review when received the request from RTG WGs.

Best regards,
Mach

> Sent: Wednesday, March 26, 2014 1:47 AM
> I am a little concerned that assigned directorate members to working groups will
> produce negative effects:
> 2) It will lead to an assumption that this one person will review all the output of a
> given WG.  I think we are actually better off if that task sometimes moves, as it
> ensures that fresh eyes are looking, for example to detect that assumptions are
> actually stated rather than merely in the minds of the WG.
> 
> Yours,
> Joel
> 
> > think about being asked to follow a single additional working group
> > that is not in RTG and may have routing related issues?
> >
> > WG adoption is quite the right time, but it is a good approximation of
> > that could benefit from review would be helpful/interesting in terms
> > of seeing the workload.
> >
> > Regards,
> > Alia
> >
> >

---

From: Alia Atlas <[email-masked]>
Date: Wed, 26 Mar 2014 08:47:32 -0400

Mach,

The discussion of asking a directorate member to pay attention to a WG list
is for WGs outside the area and doesn't
imply reviewing that WGs drafts - just giving a heads-up.

Alia

On Tue, Mar 25, 2014 at 11:52 PM, Mach Chen <[email-masked]> wrote:

> Hi all,
>
> IMHO, to make the directorate members to do more reviews in early stage is
> great idea, maybe we do not need to "officially" assign directorate members
> to working groups, but just encourage the directorate members to do the
> review when received the request from RTG WGs.
>
> Best regards,
> Mach
>
> the output of a
> sideline,
> explain
> high
> enjoyed
> one
> be
> "problem
> both

---

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 27 Mar 2014 10:17:25 +0800

Hi Adrian, Alia,

As a non-English speaker, I am very happy to see the language review.

Regarding the question "What makes it hard to get work done in the Routing
Area?", one of my concern is the relax of WG document adoption.

>From my feeling of IETF 8-10 years ago, every IETF draft will be only
adopted when the solution is concrete, complete and feasible, and got
various support from many vendors. But now it seems the draft could be
adopted if some necessary technical part is missing, or it gets support from
only one company. Many draft authors pay much attention before WG adoption,
but will focus less after adopted.

I am not sure if others have the same feeling with me. Please correct me if
I have some inaccurate understanding of IETF process.

Regards

Lizhong

From: rtg-dir [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: 2014年3月26日 3:13
To: Thomas Clausen
Cc: Adrian Farrel; [email-masked]; Alia Atlas; <[email-masked]>
Subject: Re: [RTG-DIR] Routing Area Health Check

vary by individual).

Thoughts?

Alia

On Tue, Mar 25, 2014 at 11:09 AM, Thomas Clausen <[email-masked]>
wrote:

Alia,

Thomas,

Thanks very much for your thoughts.  On the being underutilized and on
cross-area review, what do you and others in the Routing Directorate think
about being asked to follow a single additional working group that is not in
RTG and may have routing related issues?

 

For the time speedup of ADs, I'm told that it'd be really really useful to
have more active document shepherds - who can facilitate getting comments
and having them addressed.  I'm not sure how to put that into place really.
As a WG chair, I felt like I was processing and pushing few enough drafts
that I could do the shepherd job also - but I know that there are some WGs
where there is higher throughput.  It's also a good way of growing a person,
to let them see the whole process and deal with the discussions.

That is a good point. Honestly, I do not know, and am really torn on this
issue.

On one hand, sometimes having a shepherd as "go-between" to whip lazy ADs ;)
or reviewers to come back with "So, did this address your concerns?" could
perhaps be helpful. Oftentimes, however - and this is the "have been in this
for long enough to have many of the ADs on Jabber by now" - the shepherd is
just-another-go-in-the-way: popping an IM to Adrian (or whoever), getting a
resolution, moving on, is a faster way of waking him up from hibernation
than waiting for a third-party to do the same. Same for an AD holding a
discuss, adding an extra intermediary to go through ....not sold on the
idea.

So, I really do not know what to think about this. In the rare cases where I
have needed some whipping that I couldn't do myself, it has been an AD so
non-responsive that I doubt that a shepherd would do (was a long time ago)
and it required several other ADs ganging up....or (more recently) where
there was an issue with IANA requiring resolution (Adrian helped out there,
but possibly somebody else could have, too).

I agree. It was just the least-arbitrary version number I could come up with
on short notice ;)

We could ask WG chairs to request a reviewer at that point for drafts that
may need it and see what the load looks like.  For a start-up, having
interested WG chairs identify WG drafts that could benefit from review would
be helpful/interesting in terms of seeing the workload.

Can't disagree on this.

Thomas

Regards,

Alia

On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen <[email-masked]>
wrote:

I've been dumbfounded by some of the reviews I have seen from ADs, either
during AD Evaluation or IESG Reviews: one particular case came to mind where
Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker during
IESG Evaluation. It doesn't matter what document or WG it was, what matters
is that (i) it doesn't scale IETF-wide, (ii) it's poor use of Adrian's time,
(iii) there wasn't really something in the DISCUSS/COMMENTs that required
the wizardry of a yellow dot (just some routing background), and -- most
importantly -- (iv) getting a 10-page DISCUSS/COMMENT during IESG Evaluation
really isn't helpful to the document authors...its late, design decisions
have been made, which are being questioned, etc....it tires people out,
pisses off authors, and frustrates everybody involved.

Thought #1:
I-Ds - when called for adoption as WG documents, or when published as
draft-ietf-...-00's, gets someone from the directorate assigned, to provide
an initial review and thoughts on "what directions would be good to take (or
avoid) here". That same reviewer can, occasionally, be invoked by the WG
chairs or authors, in the "so, did we catch this right?" -- and, of course,
should be called in on the WGLC of the document. I think of it a little as
the "area advisors" but to a document rather than a WG as a whole.

        o       Since I know very little about security, I've looped in
somebody who did, when
                having published a -00, and again the same person as needed
later in the process.
                I've gotten  hugely valuable feedback - making the ultimate
SEC-DIR and SEC-AD
                reviews a lot  less painful for me (and, given how little I
knew about security, presumably
                less  frustrating/time-consuming for the ADs, too, than if I
had been just shooting blind).

        o       Since I know even less about OPS stuff, Adrian looped an OPS
guy in on an
                individual -01, who asked a lot of good questions to what we
were doing, and why,
                and which is hugely helpful.

As an author in the RTG Area, the SEC and OPS ADs are often real
"roadblocks". Reasonably so, of course, they represent important concerns.
And gosh, every time I encounter any AD, I have to explain the whole context
over once again since, even if they've already gotten the story once, they
have to follow sufficiently many documents and topics that something is
bound to be flushed from their cache.

In short, what I envision is a structured way of getting:
        o       very early-reviews
        o       a semi-permanent attachment of a reviewer from the
directorateS to a document
        o       this, through the documents lifecycle.

Not sure if it scales, either, but as an author I've greatly enjoyed having
such a "ongoing relationship" with people helping me avoid pitfalls.

A final note: having been around for a while in the IETF, it is really easy
to ask around for help from among other IETFers that one knows -- then
again, having been around for a while, presumably one has more experience
and needs less help in avoiding pitfalls. For a new(ish) author, who knows
few people and who presumably might be likely to need more help in avoiding
said pitfalls, it's a lot harder to actually reach out and get the right
people's eyes on a document -- and, even to know what eyes are good to get
on it.

Thought #2:
So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter version
of thought #1 is to have a more structure directorate review cycle during
IETF LC, or perhaps during "Publication Requested" and before "AD
Evaluation". I am thinking that these be of the form: an I-D hits the AD,
the responsible/sponsoring AD requests directorate reviews from all the
concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and reviewer
iterate until either (i) issues are squared off or (ii) either authors or
reviewer declare the other as "bat-crap-crazy" (or, complains that the other
side is not responsive) and raise the issue to the AD. AD moves the document
forward to "AD Evaluation" only once happy with the outcome of directorate
reviews. In short, hiving out a lot more of the "problem fixing" that
happens during these reviews off to the directorates - and leaving ADs to
process presumably "less broken" documents.

As an author, I have actually found it a LOT easier/faster to iterate with a
directorate reviewer (who has my document fresh in mind), than with an AD
who's preoccupied with a dozen or so documents at the same time, and other
emergencies. Now, mind you, some ADs are good at saying "Busy, will come
back to you in n days" -- others, alas, do "play dead" if they feel they
have more important fish to fry, and that's frustrating.

Thought #3:
I thought it's worth calling out, that either of the above are not really
related to RTG documents: I should think that RTG WG Chairs are plenty able
to do the necessary during WG processing, and as an author in the RTG Area,
I do usually know how to grab someone competent from the same area for
advice, as needed. While doing something like this intra-area can be a good
thing, the real boast that I, as document author, have felt has been through
getting cross-area feedback. Just as (being forced to be) reviewing document
outside of the RTG area has been hugely educational and.

Cheers,

Thomas

> We have reached a conclusion (which perhaps we should have come to sooner)
that
for
Sorry

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 27 Mar 2014 08:41:46 +0100

Lizhong,

I don't know if I quite agree with your generalization. Like children,
every working group is different, and every draft is different, and as
a result there are varying qualifications to WG adoption. Certainly at
the very least there needs to be some amount of interest in the WG and
a rough consensus to adopt a draft, but it's more complicated than
that. Sometimes there are drafts that are a part of a set of drafts
contributing to a coordinated overall effort. In those cases, the
barrier to WG adoption is lower because each draft is a necessary part
of the whole. In the case of a single-author stand-alone draft, the
barrier may be a bit higher to show the value of the draft, but there
have been many excellent single-author drafts and resulting RFCs.A
draft's IPR status can also affect a WG's judgement on whether to
adopt it.

But of course, in your own judgement, if you see a WG adoption poll
and you really don't think the WG should be spending its time on it,
respond to the poll! That's really all of our responsibilities.

Cheers,
Andy

---

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 27 Mar 2014 16:21:14 +0800

Andy, 
Thank you for the explanation. I fully agree that it is not an easy job to set the barrier for each draft. Setting a bit higher barrier for WG adoption will improve the document quality. An excellent single-author draft will not be killed by the barrier if it indeed values much. 

Regards
Lizhong

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: 2014年3月27日 15:42
> To: Lizhong Jin
> Cc: Alia Atlas; Thomas Clausen; Adrian Farrel; Alia Atlas; [email-masked]; rtg-
> [email-masked]
> I don't know if I quite agree with your generalization. Like children, every
> working group is different, and every draft is different, and as a result there
> are varying qualifications to WG adoption. Certainly at the very least there
> needs to be some amount of interest in the WG and a rough consensus to
> adopt a draft, but it's more complicated than that. Sometimes there are
> drafts that are a part of a set of drafts contributing to a coordinated overall
> effort. In those cases, the barrier to WG adoption is lower because each draft
> is a necessary part of the whole. In the case of a single-author stand-alone
> draft, the barrier may be a bit higher to show the value of the draft, but
> there have been many excellent single-author drafts and resulting RFCs.A
> draft's IPR status can also affect a WG's judgement on whether to adopt it.
> 
> But of course, in your own judgement, if you see a WG adoption poll and you
> really don't think the WG should be spending its time on it, respond to the
> poll! That's really all of our responsibilities.
> 
> Cheers,
> Andy
> 
> 
> > Regarding the question "What makes it hard to get work done in the
> > Routing Area?", one of my concern is the relax of WG document adoption.
> >
> > adopted if some necessary technical part is missing, or it gets
> > support from only one company. Many draft authors pay much attention
> > before WG adoption, but will focus less after adopted.
> >
> > I am not sure if others have the same feeling with me. Please correct
> > me if I have some inaccurate understanding of IETF process.
> >
> >
> >
> > Regards
> >
> > Lizhong
> >
> >
> >
> >
> >
> > WG adoption.  We have also heard that the Routing Directorate could be
> > used more (though the situation may
> >
> > vary by individual).
> >
> >
> >
> that into place really.
> > As a WG chair, I felt like I was processing and pushing few enough
> > drafts that I could do the shepherd job also - but I know that there
> > are some WGs where there is higher throughput.  It's also a good way
> > of growing a person, to let them see the whole process and deal with the
> discussions.
> >
> >
> >
> > On one hand, sometimes having a shepherd as "go-between" to whip lazy
> > ADs ;) or reviewers to come back with "So, did this address your
> > concerns?" could perhaps be helpful. Oftentimes, however - and this is
> > the "have been in this for long enough to have many of the ADs on
> > Jabber by now" - the shepherd is
> > just-another-go-in-the-way: popping an IM to Adrian (or whoever),
> > getting a resolution, moving on, is a faster way of waking him up from
> > hibernation than waiting for a third-party to do the same. Same for an
> > AD holding a discuss, adding an extra intermediary to go through
> > ....not sold on the idea.
> >
> >
> >
> > So, I really do not know what to think about this. In the rare cases
> > where I have needed some whipping that I couldn't do myself, it has
> > been an AD so non-responsive that I doubt that a shepherd would do
> > (was a long time ago) and it required several other ADs ganging
> > up....or (more recently) where there was an issue with IANA requiring
> > resolution (Adrian helped out there, but possibly somebody else could
> have, too).
> >
> >
> >
> > "early in the process".
> > We could ask WG chairs to request a reviewer at that point for drafts
> > that may need it and see what the load looks like.  For a start-up,
> > having interested WG chairs identify WG drafts that could benefit from
> > review would be helpful/interesting in terms of seeing the workload.
> >
> >
> >
> > Can't disagree on this.
> >
> >
> >
> > Thomas
> >
> >
> >
> >
> >
> > Regards,
> >
> > Alia
> >
> >
> >
> > I am probably going to cut my answer into separate independent mails,
> > as there are vastly different topics in this question.
> >
> > "under-utilized". An occasional review of an I-D at an extremely late
> > state of its process, and a very rare more global question like this.
> > As has been discussed widely lately, ADs are overworked and have too
> > little time, so perhaps they do not call on the directorate enough -
> > and, also, delegation of tasks that the ADs have to do is probably perceived
> as rather hard.
> >
> > either during AD Evaluation or IESG Reviews: one particular case came
> > to mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT
> > to the tracker during IESG Evaluation. It doesn't matter what document
> > or WG it was, what matters is that (i) it doesn't scale IETF-wide,
> > (ii) it's poor use of Adrian's time,
> > required the wizardry of a yellow dot (just some routing background),
> > and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT
> > during IESG Evaluation really isn't helpful to the document
> > authors...its late, design decisions have been made, which are being
> > questioned, etc....it tires people out, pisses off authors, and frustrates
> everybody involved.
> >
> > draft-ietf-...-00's, gets someone from the directorate assigned, to
> > provide an initial review and thoughts on "what directions would be
> > good to take (or
> > avoid) here". That same reviewer can, occasionally, be invoked by the
> > course, should be called in on the WGLC of the document. I think of it
> > a little as the "area advisors" but to a document rather than a WG as a
> whole.
> >
> > context over once again since, even if they've already gotten the
> > story once, they have to follow sufficiently many documents and topics
> > that something is bound to be flushed from their cache.
> >
> > document (and, presumably, follows much fewer documents concurrently)
> > through the process with the authors would be great, as an author. And
> > possibly makes the ADs encounter less poor documents.
> >
> > DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS folks,
> > and I have no reason to not expect Alia to have the same high (or
> > higher) standards....so I imagine that a way the RTG-DIR could help
> > "improve the image of the ADs" and at the same time get the ADs time
> > liberated from writing 10-page discusses, would be something like the
> above....
> >
> > easy to ask around for help from among other IETFers that one knows --
> > then again, having been around for a while, presumably one has more
> > experience and needs less help in avoiding pitfalls. For a new(ish)
> > author, who knows few people and who presumably might be likely to
> > need more help in avoiding said pitfalls, it's a lot harder to
> > actually reach out and get the right people's eyes on a document --
> > and, even to know what eyes are good to get on it.
> >
> > reviews from all the concerned directorates (GEN, SEC, OPS, RTG, TSP,
> > ...). Authors and reviewer iterate until either (i) issues are squared
> > "bat-crap-crazy" (or, complains that the other side is not responsive)
> > and raise the issue to the AD. AD moves the document forward to "AD
> > Evaluation" only once happy with the outcome of directorate reviews.
> > In short, hiving out a lot more of the "problem fixing" that happens
> > during these reviews off to the directorates - and leaving ADs to process
> presumably "less broken" documents.
> >
> > with a directorate reviewer (who has my document fresh in mind), than
> > with an AD who's preoccupied with a dozen or so documents at the same
> > time, and other emergencies. Now, mind you, some ADs are good at
> > saying "Busy, will come back to you in n days" -- others, alas, do
> > "play dead" if they feel they have more important fish to fry, and that's
> frustrating.
> >
> > really related to RTG documents: I should think that RTG WG Chairs are
> > plenty able to do the necessary during WG processing, and as an author
> > in the RTG Area, I do usually know how to grab someone competent from
> > the same area for advice, as needed. While doing something like this
> > intra-area can be a good thing, the real boast that I, as document
> > author, have felt has been through getting cross-area feedback. Just
> > as (being forced to be) reviewing document outside of the RTG area has
> been hugely educational and.
> >
> > Cheers,
> >
> > Thomas
> >
> >
> >

---

From: Loa Andersson <[email-masked]>
Date: Thu, 27 Mar 2014 10:49:07 +0100

Lizhong,

This is a bit odd - I've worrying a bit over the last year or two that
we are putting a too high threshold on the documents to make them
working group documents :) !

Well, we might both be right, I think we are looking at slightly
different things.

We started the MPLS review team about to years ago (for those of you
that don't know - the MPLS RT is a group of people with experiences of
mpls, that helps the working group chairs if it is time to start the
process to make a draft a working group document).

The instructions we give the the reviewers are:

Reviews should comment on whether the document is
- coherent
- useful (ie, is it likely to be actually useful in operational
   networks),
- technically sound

Now if things are missing this might show up as that the document
is not technically sound, but I think this depends quite a bit on
"how" things are missing. If we know that that it is rather
straightforward to add the missing parts, then I don't see any
reason not to adopt it as a working group document. On the the
other hand if we suspect that the missing part is a major ostacle
then we should make sure that we have a path forward.

There is a value in adopting documents as wg docs, the revision control
is taken over by the wg group, and the the authors might be given
directives (aligned with wg consensus) what to to with the document.
Also if things drags out to long, the wg for example has the
possibility to appoint an editor to drive the document.
Individual documents are up to the authors only.

The working group could also decide not to progress a working document
further.

/Loa

--

---

From: Alia Atlas <[email-masked]>
Date: Thu, 27 Mar 2014 20:57:14 +0000

My understanding is that the "routing area advisors" are for WGs where it seems the WG has a substantial amount of work that overlaps into routing.  The advisors are there primarily as a resource to the WG chairs (and WG).

In this case, the goal is to have more ears paying attention and reporting back if there are drafts that should be looked at before it's "too late".   Providing clue is also desirable, of course.

-----Original Message-----
From: Ross Callon 
Sent: Tuesday, March 25, 2014 5:27 PM
To: Joel M. Halpern; Alia Atlas; Thomas Clausen
Cc: Adrian Farrel; [email-masked]; Alia Atlas; <[email-masked]>
Subject: RE: [RTG-DIR] Routing Area Health Check

Ross

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, March 25, 2014 1:47 PM
To: Alia Atlas; Thomas Clausen
Cc: Adrian Farrel; [email-masked]; Alia Atlas; <[email-masked]>
Subject: Re: [RTG-DIR] Routing Area Health Check

I am a little concerned that assigned directorate members to working groups will produce negative effects:
1) It will lead to more scheduling conflict.
2) It will lead to an assumption that this one person will review all the output of a given WG.  I think we are actually better off if that task sometimes moves, as it ensures that fresh eyes are looking, for example to detect that assumptions are actually stated rather than merely in the minds of the WG.

Yours,
Joel

---

From: "Lizhong Jin" <[email-masked]>
Date: Fri, 28 Mar 2014 09:59:49 +0800

Hi Loa,
MPLS is doing great. And the language review team will definitely be helpful.
Since my feeling is not common, I think that is a good thing for the health of routing area. :)

Regards
Lizhong

> Sent: 2014年3月27日 17:49
> Cc: [email-masked]; [email-masked]
> Subject: Re: [RTG-DIR] Adopting wg doc - Routing Area Health Check
> 
> Lizhong,
> 
> This is a bit odd - I've worrying a bit over the last year or two that we are
> putting a too high threshold on the documents to make them working group
> documents :) !
> 
> Well, we might both be right, I think we are looking at slightly different things.
> 
> We started the MPLS review team about to years ago (for those of you that
> don't know - the MPLS RT is a group of people with experiences of mpls, that
> helps the working group chairs if it is time to start the process to make a draft
> a working group document).
> 
> Now if things are missing this might show up as that the document is not
> technically sound, but I think this depends quite a bit on "how" things are
> missing. If we know that that it is rather straightforward to add the missing
> parts, then I don't see any reason not to adopt it as a working group
> document. On the the other hand if we suspect that the missing part is a
> major ostacle then we should make sure that we have a path forward.
> 
> There is a value in adopting documents as wg docs, the revision control is
> taken over by the wg group, and the the authors might be given directives
> (aligned with wg consensus) what to to with the document.
> Also if things drags out to long, the wg for example has the possibility to
> appoint an editor to drive the document.
> > Thank you for the explanation. I fully agree that it is not an easy job to set
> the barrier for each draft. Setting a bit higher barrier for WG adoption will
> improve the document quality. An excellent single-author draft will not be
> killed by the barrier if it indeed values much.
> >
> > Regards
> > Lizhong
> >
> >> Cc: Alia Atlas; Thomas Clausen; Adrian Farrel; Alia Atlas;
> >> [email-masked]; rtg- [email-masked]
> >> I don't know if I quite agree with your generalization. Like
> >> children, every working group is different, and every draft is
> >> different, and as a result there are varying qualifications to WG
> >> adoption. Certainly at the very least there needs to be some amount
> >> of interest in the WG and a rough consensus to adopt a draft, but
> >> it's more complicated than that. Sometimes there are drafts that are
> >> a part of a set of drafts contributing to a coordinated overall
> >> effort. In those cases, the barrier to WG adoption is lower because
> >> each draft is a necessary part of the whole. In the case of a
> >> single-author stand-alone draft, the barrier may be a bit higher to
> >> show the value of the draft, but there have been many excellent single-
> author drafts and resulting RFCs.A draft's IPR status can also affect a WG's
> judgement on whether to adopt it.
> >>
> >>>  From my feeling of IETF 8-10 years ago, every IETF draft will be
> >>> only adopted when the solution is concrete, complete and feasible,
> >>> and got various support from many vendors. But now it seems the
> >>> draft could be adopted if some necessary technical part is missing,
> >>> or it gets support from only one company. Many draft authors pay
> >>> much attention before WG adoption, but will focus less after adopted.
> >>>
> >>> I am not sure if others have the same feeling with me. Please
> >>> correct me if I have some inaccurate understanding of IETF process.
> >>>
> >>>
> >>>
> >>> Regards
> >>>
> >>> Lizhong
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Adrian and I have discussed the need for good early review and
> >>> follow through of drafts starting with
> >>>
> >>> WG adoption.  We have also heard that the Routing Directorate could
> >>> be used more (though the situation may
> >>>
> >>> vary by individual).
> >>>
> >>>
> >>>
> >>> As far as English language mentoring, it sounds like George, Loa,
> >>> and Ross have a trial run going in MPLS.
> >>>
> >>> We can discuss having common organization for volunteers on each
> >>> WG's wiki or on the routing-area wiki.
> >>>
> >>>
> >>>
> >>> Thoughts?
> >>>
> >>>
> >>>
> >>> Alia
> >>>
> >>>
> >>>
> >>> On one hand, sometimes having a shepherd as "go-between" to whip
> >>> lazy ADs ;) or reviewers to come back with "So, did this address
> >>> your concerns?" could perhaps be helpful. Oftentimes, however - and
> >>> this is the "have been in this for long enough to have many of the
> >>> ADs on Jabber by now" - the shepherd is
> >>> getting a resolution, moving on, is a faster way of waking him up
> >>> from hibernation than waiting for a third-party to do the same. Same
> >>> for an AD holding a discuss, adding an extra intermediary to go
> >>> through ....not sold on the idea.
> >>>
> >>>
> >>>
> >>> up....or (more recently) where there was an issue with IANA
> >>> requiring resolution (Adrian helped out there, but possibly somebody
> >>> else could
> >> have, too).
> >>>
> >>>
> >>>
> >>> of "early in the process".
> >>>
> >>>
> >>>
> >>> We could ask WG chairs to request a reviewer at that point for
> >>> drafts that may need it and see what the load looks like.  For a
> >>> start-up, having interested WG chairs identify WG drafts that could
> >>> benefit from review would be helpful/interesting in terms of seeing the
> workload.
> >>>
> >>>
> >>>
> >>> Can't disagree on this.
> >>>
> >>>
> >>>
> >>> Thomas
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Alia
> >>>
> >>>
> >>>
> >>> late state of its process, and a very rare more global question like this.
> >>> DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the
> >>> document authors...its late, design decisions have been made, which
> >>> are being questioned, etc....it tires people out, pisses off
> >>> authors, and frustrates
> >> everybody involved.
> >>>
> >>> be good to take (or
> >>> avoid) here". That same reviewer can, occasionally, be invoked by
> >>> the WG chairs or authors, in the "so, did we catch this right?" --
> >>> and, of course, should be called in on the WGLC of the document. I
> >>> think of it a little as the "area advisors" but to a document rather
> >>> than a WG as a
> >> whole.
> >>>
> concerns.
> >>> story once, they have to follow sufficiently many documents and
> >>> topics that something is bound to be flushed from their cache.
> >>>
> >>> (or
> directorate reviews.
> >>>> The crunch question for us is "What makes it hard to get work done
> >>>> in the Routing Area?" What gets in the way of your work? What is
> >>>> making life hard for document authors? How could working groups be
> >>>> doing better? We are open to all and every type of answer. We are
> >>>> happy to have quick, one-line answers or deeply-considered essays.
> >>>>
> >>>> What do you think?
> >>>>

---

From: "Russ White" <[email-masked]>
Date: Fri, 28 Mar 2014 14:30:37 -0400

> "unsafe to deploy" to me.

Path protection is specifically an area that I think needs to be returned to
research for various reasons.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Fri, 28 Mar 2014 14:48:50 -0400

> about being asked to follow a single additional working group that is not
in
> RTG and may have routing related issues?

I actually like this idea, so long as we don't (as Joel pointed out) simply
assign every review from that WG to the one "watcher."

:-)

Russ