Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 21 Jul 2014 17:02:38 +0200

Hey A^2,

I may have missed it, but was there a room announced for this event — or, is the recommended to stalk either of you after the morning sessions, and see where that takes us?

Cheers,

Thomas
 
> On 24 Jun 2014, at 22:14 , Adrian Farrel <[email-masked]> wrote:
> 
> Chairs and Directorate,
> 
> Alia and I have blocked out a slot in Toronto for you to come and discuss Area
> reorganisation with us.
> 
> We have found Tuesday 12.00 to 14.00 doesn't conflict with any RTG WG meetings,
> so we suggest "grab lunch and come along". Room to be announced.
> 
> The meeting will not be announced wider than this grouping, but will not be a
> private meeting so it is possible that other will drift in. We will not throw
> them out!
> 
> Thanks for the discussions on the various lists so far and please stay engaged.
> 
> Adrian and Alia
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 21 Jul 2014 11:54:13 -0400

The meeting is on Tuesday from 12pm to 2pm in the Quebec room.

Thanks for the reminder to send it the room info.

Alia
On Jul 21, 2014 11:03 AM, "Thomas Heide Clausen" <[email-masked]>
wrote:

> Hey A^2,
>
> I may have missed it, but was there a room announced for this event — or,
> is the recommended to stalk either of you after the morning sessions, and
> see where that takes us?
>
> Cheers,
>
> Thomas
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 21 Jul 2014 17:57:19 +0200

Awesome, Alia, thanks a ton. See all y'all tomorrow, then.

Thomas

> On 21 Jul 2014, at 17:54 , Alia Atlas <[email-masked]> wrote:
> 
> On Jul 21, 2014 11:03 AM, "Thomas Heide Clausen" <[email-masked]> wrote:
> Hey A^2,
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 22 Jul 2014 08:54:40 -0400

Because the question has come up a couple times, this meeting is a "bring
your own lunch".

See you at noon in the Quebec room.

Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Jul 2014 10:24:07 -0400

I will not be able to make it to the meeting due to a conflicting meeting.

Several people have mentioned an idea that apparently was floated, but 
which I missed if it was on the list.
THe idea is to separate requirements generation (for various activities) 
from protocol generation to address those requirements.  Not just 
separate them in time (we do that) but put them in different working groups.

This strikes me as likely to cause trouble.  Whether other folks have 
succeeded with this or not, the way the IETF works our requirements work 
is neither divorced from the solutions nor is it typically complete 
enough to be fully understood without context.  So throwing requirements 
over a wall from one WG to another seems ineffective.  One could argue 
that this separation is what KARPO did.  But I would say that KARP did 
requirements, GAP Analysis, and then participated in the work on 
solution development for several iterations.  In fact several times the 
work started in KARP, and only moved to the specific protocol group when 
it was reasonably clear that the problem was being addressed.

Just a thought,
Joel

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 22 Jul 2014 15:06:59 +0000

Joel, and all,
I agree with Joel: administrative separation of requirements and protocol work is a highly problematic idea.

I assume that we would not like to postpone beginning of the WG work on the protocol  until the requirement document is approved for publication as an RFC; but if we run these two in parallel, synchronizing ongoing changes in the requirements with changes in the solution would become a complex cross-WG task. 

And consider the case when in order to address requirements we would need changes in more than one protocol? CCAMP work on GMPLS provides lots of examples when requirements to provide a GMPLS-controlled non-packet network require coordinated changes in RSVP-TE, LMP, OSPF-TE and IS-IS-TE... Just planning the sessions of the affected WGs during an IETF meeting to avoid conflicts would become highly non-trivial IMO...

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

> -----Original Message-----
> From: rtg-dir [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Tuesday, July 22, 2014 5:24 PM
> To: Alia Atlas; Thomas Clausen
> Cc: Adrian Farrel; [email-masked]; [email-masked]
> Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto -- input
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 22 Jul 2014 11:09:52 -0400

Joel,

First I've heard of that idea...

Alia

On Tue, Jul 22, 2014 at 10:24 AM, Joel M. Halpern <[email-masked]>
wrote:

> from protocol generation to address those requirements.  Not just separate
> them in time (we do that) but put them in different working groups.
>
> succeeded with this or not, the way the IETF works our requirements work is
> neither divorced from the solutions nor is it typically complete enough to
> be fully understood without context.  So throwing requirements over a wall
> from one WG to another seems ineffective.  One could argue that this
> separation is what KARPO did.  But I would say that KARP did requirements,
> GAP Analysis, and then participated in the work on solution development for
> several iterations.  In fact several times the work started in KARP, and
> only moved to the specific protocol group when it was reasonably clear that
> the problem was being addressed.
>
> Just a thought,
> Joel
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Jul 2014 11:31:40 -0400

While I agree with both sasha's and Joels comments on separation, and
don't generally believe such is a good idea, it could yield smaller wgs
with less signal-to-noise ratio -- which seems to be one of the
objectives of this discussion...

lou

---

From: Loa Andersson <[email-masked]>
Date: Wed, 23 Jul 2014 00:49:29 +0200

Folks,

I took a look at the performance on rtg wg's.

The spread sheet list the number of RFC's per working group
between two meeting. I've used the number of people who signed the
blue sheets in Vancouver as some type of average except for roll
that did not meet in Vancouver, where I used the London figure instead.

Calculated the number of RFCs per person in the room.

The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting.
The highest absolute number of RFC is MPLS (this meeting).
The best trend has MPLS.

Since I don't care too much about how much noise the non-participating
participants is exposed too, I don't think the a re-org is motivated
by the figures in the spread sheet.

I guess I would go as far as too say that no arguments presented so far
motivates a re-org of the RTG area.

Though I'm totally supportive of some well considered re-organization
of working groups, but

- do it carefully
- at a time when it is optimal for the working groups
- involve the chairs to drive the re-org
- don't break things that work

/Loa

-- 

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

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 23 Jul 2014 10:45:37 +0800

I also agree this is not a good idea. There are many protocol enhancements draft raised in the WG, and these drafts solve real problem, but there may not separate requirement document, instead the requirement is incorporated into the solution draft. Separate requirements and protocol to different WGs may cause additional administrative coordination work.

Lizhong

> From: rtg-dir [mailto:[email-masked]] On Behalf Of Alexander
> Vainshtein
> Sent: 2014年7月22日 23:07
> To: Joel M. Halpern
> Cc: Thomas Clausen; Adrian Farrel; Alia Atlas; [email-masked]; rtg-
> [email-masked]
> I assume that we would not like to postpone beginning of the WG work on
> the protocol  until the requirement document is approved for publication as
> an RFC; but if we run these two in parallel, synchronizing ongoing changes in
> the requirements with changes in the solution would become a complex
> cross-WG task.
> 
> And consider the case when in order to address requirements we would
> need changes in more than one protocol? CCAMP work on GMPLS provides
> lots of examples when requirements to provide a GMPLS-controlled non-
> packet network require coordinated changes in RSVP-TE, LMP, OSPF-TE and
> IS-IS-TE... Just planning the sessions of the affected WGs during an IETF
> meeting to avoid conflicts would become highly non-trivial IMO...
> 
> My 2c,
>        Sasha
> > THe idea is to separate requirements generation (for various
> > activities) from protocol generation to address those requirements.
> > Not just separate them in time (we do that) but put them in different
> > working groups.
> >
> > succeeded with this or not, the way the IETF works our requirements
> > work is neither divorced from the solutions nor is it typically
> > complete enough to be fully understood without context.  So throwing
> > requirements over a wall from one WG to another seems ineffective.
> > One could argue that this separation is what KARPO did.  But I would
> > say that KARP did requirements, GAP Analysis, and then participated in
> > the work on solution development for several iterations.  In fact
> > several times the work started in KARP, and only moved to the specific
> > protocol group when it was reasonably clear that the problem was being
> addressed.
> >
> > Just a thought,
> > Joel

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 22 Jul 2014 22:55:15 -0400

Loa,

I added one more column, to total all of the RFCs over the period. mpls
came in first in terms of total RFCs per capita, and pwe3 came in second. I
also agree with your conclusions.

Cheers,
Andy

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Jul 2014 06:55:47 -0400

Giles: 

The performance that IETF has utilized for its ADs, IETF chairs, and WG
groups for 20 years has been:

Quantitative: 

1)      RFC published 

2)      WG groups formed and completed

3)      Administrative effectiveness (AFI/SAFIs, early code adoption, ports
assigned. )

4)      Number of authors and demographics on authors 

5)      Statistics on the timing of RFCs and the timing of WG forming 

6)      Statistics on attendance in WG/ IETF 

Please note, I do know of a statistically valid analysis of the correlation
between #6 an #1.  If you do, I would be interested. 

Qualitatively 

1)      Technologies described in RFCs get deployed. 

2)      IETF is collaborative (at IESG, at WG), 

3)      People want to come (from surveys)   

The "people" want to come falls into a qualitative experience that says
"important to learn about the technology". 

http://www.arkko.com/tools/docstats.html  has document statistics. 

If you want to propose a new metric it can be useful going forward, but
unless it is built on the data kept by the datatracker, we do not have the
past trends to defend it.   You could also use the mail list information,
but we would need to use a long-running group to get a valid statistics. 

Sue 

From: Giles Heron (giheron) [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2014 6:32 AM
To: Andrew G. Malis
Cc: Loa Andersson; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] what is so bad

I'm not sure that how helpful the exercise is?  Is performance really
related to how many people show up?  There's no way after all to determine
what fraction of attendees are active participants vs "IETF tourists".  And
of course we're supposed to do more work outside meetings than in them.

At any rate to be meaningful at all we need to weight the results by length
of WG meeting as time is the constraint we're trying to optimise for here (I
think!).  I counted WG meeting durations in minutes (since L2VPN was 2 hours
10 mins - and I didn't have the time to type a recurring decimal).  Couldn't
find ROLL on the Vancouver Agenda though - so I used their London duration.
Of course then the RFCs per minute were all rather low.  In honour of the
recent World Cup I went for RFCs per football match (counting only the
players and the playing minutes - no allowance for referees, half-time,
injury time or extra time).

the results show PWE3 a mile ahead of the rest, followed by BFD, then MPLS,
then a cluster of WGs with very similar productivity (L2VPN leading those by
a nose, but who am I to brag?) with L3VPN and then PCE (possibly the victim
of the recent SDN hype) bringing up the rear.

like I say, does this really mean anything?   Can I have the last half hour
of my life (or rather 1/66 of a football match) back?

Giles

> <statsv2.xlsx>

---

From: John Scudder <[email-masked]>
Date: Wed, 23 Jul 2014 11:24:15 +0000

On Jul 23, 2014, at 7:12 AM, "Giles Heron (giheron)" <[email-masked]> wrote:
> I think my point was rather that I'm not sure metrics are what we should be concentrating on in this debate.  Numbers can be made to say just about anything, after all ;)

That was more-or-less the point I had been waiting to make when we ran out of time yesterday. That, plus, bad (or the wrong) metrics are worse than no metrics, so take care. 

--John

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Jul 2014 07:30:05 -0400

Alia/Adrian,

While this point didn't come up directly yesterday, perhaps due to Joel's 
absence, there is a case in your plan. In particular TE routing occurs in 
the core protocol group (s) while requirements come from the new TE group.

As others have mentioned,  we've had very good success in developing TE 
routing extensions together with requirements,  framework and signaling in 
ccamp, with good cooperation and support of the related IGP WG.

If you do decided to go a head with the reorganization as described 
yesterday,  I think excluding TE routing solutions from the te 
'requirements and signalling' group qualifies as the issue raised by Joel.

Lou

---

From: "Giles Heron (giheron)" <[email-masked]>
Date: Wed, 23 Jul 2014 10:32:27 +0000

I'm not sure that how helpful the exercise is?  Is performance really related to how many people show up?  There's no way after all to determine what fraction of attendees are active participants vs "IETF tourists".  And of course we're supposed to do more work outside meetings than in them.

At any rate to be meaningful at all we need to weight the results by length of WG meeting as time is the constraint we're trying to optimise for here (I think!).  I counted WG meeting durations in minutes (since L2VPN was 2 hours 10 mins - and I didn't have the time to type a recurring decimal).  Couldn't find ROLL on the Vancouver Agenda though - so I used their London duration.  Of course then the RFCs per minute were all rather low.  In honour of the recent World Cup I went for RFCs per football match (counting only the players and the playing minutes - no allowance for referees, half-time, injury time or extra time).

the results show PWE3 a mile ahead of the rest, followed by BFD, then MPLS, then a cluster of WGs with very similar productivity (L2VPN leading those by a nose, but who am I to brag?) with L3VPN and then PCE (possibly the victim of the recent SDN hype) bringing up the rear.

like I say, does this really mean anything?   Can I have the last half hour of my life (or rather 1/66 of a football match) back?

Giles

On 23 Jul 2014, at 03:55, Andrew G. Malis <[email-masked]> wrote:

> Loa,
>
> I added one more column, to total all of the RFCs over the period. mpls came in first in terms of total RFCs per capita, and pwe3 came in second. I also agree with your conclusions.
>
> Cheers,
> Andy
>
>

---

From: "Giles Heron (giheron)" <[email-masked]>
Date: Wed, 23 Jul 2014 11:03:05 +0000

Hi Sue,

Giles

On 23 Jul 2014, at 11:55, Susan Hares <[email-masked]> wrote:

> Giles:
>  
> The performance that IETF has utilized for its ADs, IETF chairs, and WG groups for 20 years has been:
>  
> Quantitative:
> 1)      RFC published
> 3)      Administrative effectiveness (AFI/SAFIs, early code adoption, ports assigned… )
> Please note, I do know of a statistically valid analysis of the correlation between #6 an #1.  If you do, I would be interested.
>  
> Qualitatively
> The “people” want to come falls into a qualitative experience that says “important to learn about the technology”.
>  
> If you want to propose a new metric it can be useful going forward, but unless it is built on the data kept by the datatracker, we do not have the past trends to defend it.   You could also use the mail list information, but we would need to use a long-running group to get a valid statistics.
>  
> Sue

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 23 Jul 2014 12:51:25 +0000

Hi all,
One example of "what is bad" is the cases when drafts reach advanced stage (or even are published as RFCs) with serious technical problems/gaps.

E.g., I have just now submitted an Errata to RFC 7257 "Virtual Private LAN Service (VPLS) Management Information Base" reporting what I see as a serious technical gap in an RFC that has been published earlier this month.

Another example is, IMO, https://datatracker.ietf.org/doc/draft-ietf-mpls-deprecate-bgp-entropy-label: in this case the authors have discovered a serious bug in an already published RFC 6970 that requires deprecation of one of its elements.

While these case may be relatively rare, the definitely fall under the general category of "what is bad" IMO.

I cannot point to any specific organizational or process change that would reduce the number of these cases. But at least it makes sense to me to consider them as valid use cases for estimating such changes.

My 2c,
       Sasha 

> From: rtg-dir [mailto:[email-masked]] On Behalf Of John Scudder
> Sent: Wednesday, July 23, 2014 2:24 PM
> To: Giles Heron (giheron)
> Cc: [email-masked]; [email-masked]; Andrew G. Malis; Susan Hares; Loa
> Andersson
> > I think my point was rather that I'm not sure metrics are what we should be
> concentrating on in this debate.  Numbers can be made to say just about
> anything, after all ;)
> 
> That was more-or-less the point I had been waiting to make when we ran out
> of time yesterday. That, plus, bad (or the wrong) metrics are worse than no
> metrics, so take care.
> 
> --John

Subject: [Technical Errata Reported] RFC7257 (4059)
From: RFC Errata System <[email-masked]>
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]" <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 23 Jul 2014 12:37:32 +0000

The following errata report has been submitted for RFC7257,
"Virtual Private LAN Service (VPLS) Management Information Base".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7257&eid=4059

--------------------------------------
Type: Technical
Reported by: Alexander ("Sasha") Vainshtein <[email-masked]>

Section: 6

Original Text
-------------
N/A - this is about some missing MIB objects that should be there

Corrected Text
--------------
N/A - this is hardly the right place to define missing MIB objects

Notes
-----
As per RFC 4762 (which defines at least one of the two VPLS types for which this RFC defines Management Information Base), Virtual Switching Instance (VSI)(a local representation of a given VPLS instance within a given PE) is connected to CE devices via Attachment Circuits (AC). Hence I would expect that Management Information Base for VPLS would provide for some representation of ACs that perform this function for a given VSI.

However, this RFC does not even mention attachment circuits in any way.

I have tried to raise this issue with the WG and the authors. One of the authors has replied (see http://www.ietf.org/mail-archive/web/l2vpn/current/msg04539.html) that "ACs are attached to the VPLS instances and are represented as IfMIB entries". However, neither Interfaces MIB nor any of its key elements (e.g., ifIndex) are mentioned in this RFC.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7257 (draft-ietf-l2vpn-vpls-mib-15)
--------------------------------------
Title               : Virtual Private LAN Service (VPLS) Management Information Base
Publication Date    : July 2014
Author(s)           : T. Nadeau, Ed., A. Kiran Koushik, Ed., R. Mediratta, Ed.
Category            : PROPOSED STANDARD
Source              : Layer 2 Virtual Private Networks
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Loa Andersson <[email-masked]>
Date: Wed, 23 Jul 2014 15:10:58 +0200

Giles and John,

On 2014-07-23 12:32, Giles Heron (giheron) wrote:

Giles:
> like I say, does this really mean anything?   Can I have the last half
> hour of my life (or rather 1/66 of a football match) back?

John:
"bad (or the wrong) metrics are worse than no metric"

You make my point! What I did to try to see if I by some simple 
(non-scientific) method could find some proof of what has been in this
debate from the beginning.

Restating this slightly
"Giant working groups are inefficient since a large number of people
  will have to spend boring time listening to discussions/presentations
  on thing they are not interested in."

Giant where not defined and the problem with statements that are made
over and over again is that they over time become "true" even if there
are nothing to substantiate them. Over time they become as bad as bad
statistic!

I don't think the original slide show anything that support the
allegation above. It is true that the number of people in the room,
the length of football matches, slot duration, the weather outside,
the location, etc.

If there is a small conclusion we can draw ii is that the people that
are interested come to the wg meetings and we make good progress
regardless of how many drone or tourists we have in the meeting.

There has also been alleged that big groups have a higher ratio of
drones, I can't find any support for that allegation.

In summary - the metrics I have is useless when it comes to motivate or
de-motivate an area re-org.

To repeat what in the first mail, and which I think it would be good to
converge on:

I'm totally supportive of some well considered re-organization
of working groups,

- don't re-org the area, re-org working groups
- do it carefully
- at a time when it is optimal for the working groups
- involve the chairs to drive the re-org
- don't break things that work

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 23 Jul 2014 15:30:56 +0200

Sasha,

I agree that what you list are example of "bad things"!

However, I don't see how it is related to a re-org of the area (which I
also think is a bad idea) or of wg groups (which at times might be a
very good idea).

This I think is more related to another (good) initiative taken by the
AD's - the working chair training; it also could be related to
initiatives taken by some wg chairs, the wg review  teams!

It might be of interest that what is now RFC 6790 (which is the RFC I
think you mean) was accepted as a wg doc before the MPLS-RT were looking
at all MPLS drafts.

/Loa

--

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Jul 2014 09:46:39 -0400

Giles:

Ah... Do you have a proposal for what you consider valid, and reasons for
abandoning the traditional statistics. 

Sue 

-----Original Message-----
From: Giles Heron (giheron) [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2014 7:03 AM
To: Susan Hares
Cc: Andrew G. Malis; Loa Andersson; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] what is so bad

Hi Sue,

Giles

groups for 20 years has been:
> 3)      Administrative effectiveness (AFI/SAFIs, early code adoption,
ports assigned. )
> Please note, I do know of a statistically valid analysis of the
correlation between #6 an #1.  If you do, I would be interested.
> 
> At any rate to be meaningful at all we need to weight the results by
length of WG meeting as time is the constraint we're trying to optimise for
here (I think!).  I counted WG meeting durations in minutes (since L2VPN was
2 hours 10 mins - and I didn't have the time to type a recurring decimal).
Couldn't find ROLL on the Vancouver Agenda though - so I used their London
duration.  Of course then the RFCs per minute were all rather low.  In
honour of the recent World Cup I went for RFCs per football match (counting
only the players and the playing minutes - no allowance for referees,
half-time, injury time or extra time).
> 
> the results show PWE3 a mile ahead of the rest, followed by BFD, then
MPLS, then a cluster of WGs with very similar productivity (L2VPN leading
those by a nose, but who am I to brag?) with L3VPN and then PCE (possibly
the victim of the recent SDN hype) bringing up the rear.
> > The spread sheet list the number of RFC's per working group between 
> > two meeting. I've used the number of people who signed the blue 
> > sheets in Vancouver as some type of average except for roll that did 
> > not meet in Vancouver, where I used the London figure instead.
> > 
> > Since I don't care too much about how much noise the 
> > non-participating participants is exposed too, I don't think the a 
> > re-org is motivated by the figures in the spread sheet.
> > 
> > I guess I would go as far as too say that no arguments presented so 
> > far motivates a re-org of the RTG area.
> > 
> > Though I'm totally supportive of some well considered 
> > re-organization of working groups, but
> > 
> > - do it carefully

---

From: Loa Andersson <[email-masked]>
Date: Wed, 23 Jul 2014 15:58:53 +0200

Sue,

I don't think that Giles says that we should abandon traditional
statistics, merely that the "numbers" the way I used can be made to
show what you want them to show. And sure I agree to that.

I further think that there are no way to actually
show what has been alleged about giant groups and long periods of
uninteresting presentations. It is simply not true. Though it is
possible to to make it seem true by repeating it often enough.

I would be in favor of having some useful traditional statistics
available per working group if it can be achieved with a reasonable
amount of work.

/Loa

--

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 23 Jul 2014 13:59:19 +0000

Loa,
Lots of thanks for a prompt and encouraging in a way) response.

I have already said in my email that "I cannot point to any specific organizational or process change that would reduce the number of these cases".

This seems to me pretty close what you  have said in your email: these problems should be handled by introducing some new elements in the process (intra-WG, inter-WG or both) rather than by re-shuffling the WGs.

I wonder if we could collect some statistics related to quality of our documents.  E.g., number of validated technical errata? number of iterations of the draft after the WG has requested its publication and until it has been approved for publication? This seems to me more relevant than the number of people attending the WG F2F sessions (possibly because I have not been attending them for quite some time;-).

My 2c,
       Sasha 

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Wednesday, July 23, 2014 4:31 PM
> To: Alexander Vainshtein; John Scudder; Giles Heron (giheron)
> Cc: [email-masked]; [email-masked]; Andrew G. Malis; Susan Hares
> However, I don't see how it is related to a re-org of the area (which I also
> think is a bad idea) or of wg groups (which at times might be a very good
> idea).
> 
> This I think is more related to another (good) initiative taken by the AD's - the
> working chair training; it also could be related to initiatives taken by some wg
> chairs, the wg review  teams!
> 
> It might be of interest that what is now RFC 6790 (which is the RFC I think you
> mean) was accepted as a wg doc before the MPLS-RT were looking at all
> MPLS drafts.
> 
> /Loa
> 
> 
> 
> > One example of "what is bad" is the cases when drafts reach advanced
> stage (or even are published as RFCs) with serious technical problems/gaps.
> >
> > E.g., I have just now submitted an Errata to RFC 7257 "Virtual Private LAN
> Service (VPLS) Management Information Base" reporting what I see as a
> serious technical gap in an RFC that has been published earlier this month.
> >
> > Another example is, IMO, https://datatracker.ietf.org/doc/draft-ietf-mpls-
> deprecate-bgp-entropy-label: in this case the authors have discovered a
> serious bug in an already published RFC 6970 that requires deprecation of
> one of its elements.
> >
> > I cannot point to any specific organizational or process change that would
> reduce the number of these cases. But at least it makes sense to me to
> consider them as valid use cases for estimating such changes.
> >
> > My 2c,
> >         Sasha
> >> Cc: [email-masked]; [email-masked]; Andrew G. Malis; Susan
> >> Hares; Loa Andersson
> >> On Jul 23, 2014, at 7:12 AM, "Giles Heron (giheron)"
> >> <[email-masked]>
> >> wrote:
> >> concentrating on in this debate.  Numbers can be made to say just
> >> about anything, after all ;)
> >>
> >> That was more-or-less the point I had been waiting to make when we
> >> ran out of time yesterday. That, plus, bad (or the wrong) metrics are
> >> worse than no metrics, so take care.
> >>
> >> --John
> 
> --
> 
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Jul 2014 10:26:30 -0400

> the victim of the recent SDN hype) bringing up the rear.

PWE3 beat BFD?  Wow... we'll have to step up productivity in BFD then. :-)

To some extent, this was the source of my strong disapproval of the
functional merge.  For BFD, what we have seems to be working.  We didn't
meet for a while because it was unnecessary.  When we did, drafts moved
along very quickly.

I agree we should address the functional grouping issues.  The solution
space is what I question.

-- Jeff

---

From: Loa Andersson <[email-masked]>
Date: Wed, 23 Jul 2014 16:37:35 +0200

Jeff,

On 2014-07-23 16:26, Jeffrey Haas wrote:
>   For BFD, what we have seems to be working.

I think this is key - what we have for BFD is working!

Further, BFD is not generating any particular problems for
other working group.

Conclusions: Don't touch BFD.

/Loa
--

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Jul 2014 10:48:06 -0400

> Conclusions: Don't touch BFD.

That said, let's find a way to coordinate OAM across groups, including BFD.

In my discussions with Alia, I'm fond of the idea of "meta" WGs.  Individual
work functions that implement IETF process (drafts, chairs, etc.) should be
partially apportioned based on not overloading any given function or
individual.  This was part of my comment about such a merger likely
involving adding a third chair.  But as Brooks' book tells us, adding more
people simply may make late work later - simply due to the need for
increased communication in the project.  

What we definitely could use is a meeting of the meta-group, even if only on
a chairs basis, regularly.  As long as we're talking amongst each other, we
have IETF leadership level communication.

The question of whether we need IETF participant communication broadened can
be serviced by targeted presentation of related work in an appropriate
place.  That could happen either in existing WG context (preserve WG work
pipelining) or do more open meeting.

Frankly, the Monday night dinner we had with several of our key BFD members
which also included significant conversation about relationships to non-BFD
OAM (e.g. CFM) was what we really need.  

-- Jeff

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 23 Jul 2014 10:50:48 -0400

Loa,

Couple of things that will improve the stats.
1) a column of documents that are in "publication process"
2) Life cycles of the WG: Example ForCES new charter starts at IETF 87.
IETF 86 and 85 were discussions on re-charter. I am not sure how one
would go about quantifying that in a spread sheet.

I am not sure i subscribe to the quantity=quality arguement.

Sue,
The metric on "demographics and number of authors on an RFC" is easy
to hack (and has been taken advantage of before). Get all kinds of big
name corps to endorse your doc etc. I think this got so bad that
at some point it was concluded cant have more than 5 authors max.
So not sure how such a metric is useful.
http://www.arkko.com/tools/docstats.html has some really good stats
that could also be utilized as you pointed out.

How many people attend and consistency of attendance
over time is important. But i dont think you should count the first 1-3
meetings which is high tourist season (as it is right now in SFC
where i am sitting). I do think as a tourist i had a choice to be here
and my presence counts because i could have been doing something
else instead. And tourists do become tenants.

cheers,
jamal

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Jul 2014 10:58:09 -0400

Loa and Giles: 

I've check the statistics on http://www.arkko.com/tools/idauthors.txt .
These statistics do not have a link to working group or a time stamp for
drafts and RFC even though there are links in the online database. Perhaps
Jari or the tools team can help me get better data.  I will check with the
secretariat to see if they can give their numbers for WG attendance. 

Your theses are:

1. "an increase in the numbers of WG attendees does not have a correlation
to RFC production by a working group".  
2.  the RFC production has remained constant in the last 3 years within the
standard deviation.  

If these are your two proposals, I can test these fairly quickly - once I
validate the data.   Jamal noted that the inclusion of many authors on a
draft is "hacking the data".  With author information, we can observe if the
statistics of 4-5 authors differ from 1-3 authors.   

Please let me know if I have understood your concerns.  

Sue 

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2014 9:59 AM
To: Susan Hares; 'Giles Heron (giheron)'
Cc: 'Andrew G. Malis'; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] what is so bad

Sue,

I don't think that Giles says that we should abandon traditional statistics,
merely that the "numbers" the way I used can be made to show what you want
them to show. And sure I agree to that.

I further think that there are no way to actually show what has been alleged
about giant groups and long periods of uninteresting presentations. It is
simply not true. Though it is possible to to make it seem true by repeating
it often enough.

I would be in favor of having some useful traditional statistics available
per working group if it can be achieved with a reasonable amount of work.

/Loa

On 2014-07-23 15:46, Susan Hares wrote:
> Giles:
>
> Ah... Do you have a proposal for what you consider valid, and reasons 
> for abandoning the traditional statistics.
>
> Sue
>
> I think my point was rather that I'm not sure metrics are what we 
> should be concentrating on in this debate.  Numbers can be made to say 
> just about anything, after all ;)
>
> Giles
>
> related to how many people show up?  There's no way after all to 
> determine what fraction of attendees are active participants vs "IETF 
> tourists".  And of course we're supposed to do more work outside meetings
than in them.
> length of WG meeting as time is the constraint we're trying to 
> optimise for here (I think!).  I counted WG meeting durations in 
> minutes (since L2VPN was
> Couldn't find ROLL on the Vancouver Agenda though - so I used their 
> London duration.  Of course then the RFCs per minute were all rather 
> low.  In honour of the recent World Cup I went for RFCs per football 
> match (counting only the players and the playing minutes - no 
> allowance for referees, half-time, injury time or extra time).
>>
> MPLS, then a cluster of WGs with very similar productivity (L2VPN 
> leading those by a nose, but who am I to brag?) with L3VPN and then 
> PCE (possibly the victim of the recent SDN hype) bringing up the rear.
>>
> came in first in terms of total RFCs per capita, and pwe3 came in 
> second. I also agree with your conclusions.
>>>
>>> Cheers,
>>> Andy
>>>
>>>

--

---

From: Ross Callon <[email-masked]>
Date: Wed, 23 Jul 2014 15:55:51 +0000

> I wonder if we could collect some statistics related to quality of our documents.  E.g.,
> number of validated technical errata? 

One small nit: If a protocol specification is widely implemented, then it may be more likely to develop technical errata when compared to a specification which is not implemented at all (if only because a lot of people are looking at it very closely). Being widely implemented however might be a sign of quality, rather than lack of quality. 

Which of course points to the observation that it can be difficult to interpret statistics. 

Ross

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, July 23, 2014 9:59 AM
To: Loa Andersson
Cc: [email-masked]; Giles Heron (giheron); Andrew G. Malis; [email-masked]; John Scudder; Susan Hares
Subject: Re: [RTG-DIR] what is so bad

Loa,

My 2c,
       Sasha 

> >>> should be

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 23 Jul 2014 17:25:25 +0000

Ross,
Lots of thanks for an important (at least, to me) coment.

Of course a protocol that is widely deployed is (a) most probably reasonably good and (b) may have multiple errata reported because many people have been implementing and/or using it.

Collecting reliable statistics about actual implementation and, especially, deployment, is not simple. At the same time I still wonder why the Routing Area has removed its once requirement to have at least one implementation for the drafts that are intended for the PS status. 

My 2c,
Sasha    
________________________________________
From: Ross Callon <[email-masked]>
Sent: Wednesday, July 23, 2014 6:55 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [RTG-DIR] what is so bad

Ross

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, July 23, 2014 9:59 AM
To: Loa Andersson
Cc: [email-masked]; Giles Heron (giheron); Andrew G. Malis; [email-masked]; John Scudder; Susan Hares
Subject: Re: [RTG-DIR] what is so bad

Loa,

My 2c,
       Sasha

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Wed, 23 Jul 2014 19:50:35 +0000

Sounds like a good idea to me.  Ops is about to charter a centralized OAM
reporting group. We should include them as well.

Along the lines of your second point we could experiment with an OAM mail
list. It'd be great if we could schedule the presentations (assuming they
would be short) in the rtgarea meeting.

George

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Jul 2014 16:03:53 -0400

Ross:   

If you get the RFC errata sub-classed into editorial (not-quality
indicator), and substantive errors - you might be able to get some trends
from the data.

Sue 

-----Original Message-----
From: Ross Callon [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2014 11:56 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [RTG-DIR] what is so bad

> I wonder if we could collect some statistics related to quality of our 
> documents.  E.g., number of validated technical errata?

One small nit: If a protocol specification is widely implemented, then it
may be more likely to develop technical errata when compared to a
specification which is not implemented at all (if only because a lot of
people are looking at it very closely). Being widely implemented however
might be a sign of quality, rather than lack of quality. 

Which of course points to the observation that it can be difficult to
interpret statistics. 

Ross

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Alexander
Vainshtein
Sent: Wednesday, July 23, 2014 9:59 AM
To: Loa Andersson
Cc: [email-masked]; Giles Heron (giheron); Andrew G. Malis;
[email-masked]; John Scudder; Susan Hares
Subject: Re: [RTG-DIR] what is so bad

Loa,

I have already said in my email that "I cannot point to any specific
organizational or process change that would reduce the number of these
cases".

This seems to me pretty close what you  have said in your email: these
problems should be handled by introducing some new elements in the process
(intra-WG, inter-WG or both) rather than by re-shuffling the WGs.

I wonder if we could collect some statistics related to quality of our
documents.  E.g., number of validated technical errata? number of iterations
of the draft after the WG has requested its publication and until it has
been approved for publication? This seems to me more relevant than the
number of people attending the WG F2F sessions (possibly because I have not
been attending them for quite some time;-).

My 2c,
       Sasha

> However, I don't see how it is related to a re-org of the area (which I
also
> This I think is more related to another (good) initiative taken by the
AD's - the
> It might be of interest that what is now RFC 6790 (which is the RFC I
think you
> > Another example is, IMO,
https://datatracker.ietf.org/doc/draft-ietf-mpls-

---

From: Loa Andersson <[email-masked]>
Date: Wed, 23 Jul 2014 22:05:38 +0200

Sue,

> statistics of 4-5 authors differ from 1-3 authors.

I think I agree to the first as one of "my theses", as for the second
one what I see is (for the MPLS wg) is that the number of RFC has been
slowly been increasing since we started to introduce process
improvements about 2 and a half year ago.

/Loa

--

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Wed, 23 Jul 2014 20:12:04 +0000

A giant workgroup with a potpourri of diverse topics would obviously be
bad.  A giant* workgroup of closely related items that need to play
together in many deployments IMHO does make sense.

George

*I'd call MPLS big or large.  Giant sounds like a term chosen for
rhetorical effect.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 23 Jul 2014 16:14:52 -0400

We do have a lot of cases other than OAM where cross-WG communication would
be very
useful.  I am in favor of interest-based mailing lists.  Another case is
for routing YANG modules,
especially as the inter-dependencies need to be figured out.

I have created a wiki page to track ideas for such mailing lists.  Please
put your ideas there for
tracking (and feel free to add agreement/support/disagreement).

http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgCrossWGMailingLists

Alia

On Wed, Jul 23, 2014 at 3:50 PM, George Swallow (swallow) <[email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Wed, 23 Jul 2014 22:18:08 +0200

Alia,

I hope you understand that this type of inter wg communication, to
a certain extent makes the area re-org you have been proposing
unnecessary, while we still have to look at how optimize the working
groups.

/Loa

On 2014-07-23 22:14, Alia Atlas wrote:
> We do have a lot of cases other than OAM where cross-WG communication
> would be very
> I have created a wiki page to track ideas for such mailing lists.
>   Please put your ideas there for
> On Wed, Jul 23, 2014 at 3:50 PM, George Swallow (swallow)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 7/23/14 10:48 AM, "Jeffrey Haas" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>      >work functions that implement IETF process (drafts, chairs, etc.)
>     should
>      >be
>      >What we definitely could use is a meeting of the meta-group, even
>     if only
>      >on
>      >a chairs basis, regularly.  As long as we're talking amongst each
>     other,
>      >we
>      >The question of whether we need IETF participant communication
>     broadened
>      >can

--

---

From: Alia Atlas <[email-masked]>
Date: Wed, 23 Jul 2014 16:21:40 -0400

Loa,

It is a way of addressing topics that are split and does nothing to address
WG size
and focus.   Of course we also need cross-WG communication.

Alia

On Wed, Jul 23, 2014 at 4:18 PM, Loa Andersson <[email-masked]> wrote:

>>      >That said, let's find a way to coordinate OAM across groups,
>> including
>>      >BFD.
>>      >

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Jul 2014 16:21:44 -0400

Loa:

Thank you for the correction to the second thesis.  I will use this as the
second thesis in any testing.   
Sue

PS - I'm still in the process of trying to get a data file with the WG
identified and date. 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Wednesday, July 23, 2014 4:06 PM
To: Susan Hares; 'Giles Heron (giheron)'
Cc: [email-masked]; 'Andrew G. Malis'; [email-masked]
Subject: Re: [RTG-DIR] what is so bad

Sue,

On 2014-07-23 16:58, Susan Hares wrote:
> These statistics do not have a link to working group or a time stamp 
> for drafts and RFC even though there are links in the online database. 
> Perhaps Jari or the tools team can help me get better data.  I will 
> check with the secretariat to see if they can give their numbers for WG
attendance.
>
> Your theses are:
>
> 1. "an increase in the numbers of WG attendees does not have a 
> correlation to RFC production by a working group".
> 2.  the RFC production has remained constant in the last 3 years 
> within the standard deviation.
>
> draft is "hacking the data".  With author information, we can observe 
> if the statistics of 4-5 authors differ from 1-3 authors.

I think I agree to the first as one of "my theses", as for the second one
what I see is (for the MPLS wg) is that the number of RFC has been slowly
been increasing since we started to introduce process improvements about 2
and a half year ago.

/Loa

> I further think that there are no way to actually show what has been 
> alleged about giant groups and long periods of uninteresting 
> presentations. It is simply not true. Though it is possible to to make 
> it seem true by repeating it often enough.
>
> available per working group if it can be achieved with a reasonable amount
of work.
>> should be concentrating on in this debate.  Numbers can be made to 
>> say just about anything, after all ;)
>>
>> Giles
>>
>>>> sheets in Vancouver as some type of average except for roll that 
>>>> did not meet in Vancouver, where I used the London figure instead.
>>>>

--

---

From: Russ White <[email-masked]>
Date: Wed, 23 Jul 2014 16:25:46 -0400

So... I hate to try and bring us back to basics, but I'm not certain I understand the goals very well. I think I heard:

- increase participation
- increase productivity

The second I take to mean faster progress from idea to wg to draft... I suspect there is a third, which is to provide more direction in an architectural sense to the area. The challenges, it seems to me, are:

- momentum
- the nature of IETF work (customer driven through vendors)
- understanding what "participation" means

I don't know if the proposed reorg would "solve" these problems. It seems, to me, that it makes sense to rethink things, but that rethinking might mean more than "just" shuffling wg's around. Maybe we need to be more intentional about using experimental status, to speed up getting work through without committing to the standards track. Part of the problem, I think, is our focus on getting things to standards.

I do like the idea of taking a more architectural view, and trying to find ways to bring more general resources to bear on more specific problems, I'm not certain how to do it. Specifically, the Oma issues we seem to be relearning from the ground up each time we approach that problem set, which seems inefficient. It would be nice to get the point where extensions to OSPF and is-is once, rather than once per protocol, but I don't know how to get from where we are to there.

:-)

Russ

---

From: Loa Andersson <[email-masked]>
Date: Wed, 23 Jul 2014 22:27:51 +0200

Sue,

I have one gut feeling that I don't know how much impact it will have
on your result, I think that we can assume the a wg that produces
"a lot of drafts" might attract more tourist, which might cause a
correlation between the number of "participants" in the wg and the
number of RFCs.

I can't say if this is strong enough to show up in the results.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 23 Jul 2014 22:30:43 +0200

Alia,

What in your mind is the correlation between "wg size" and "focus"? And
what your metrics for "wg size" is?

/Loa

On 2014-07-23 22:21, Alia Atlas wrote:
> Loa,
>
> It is a way of addressing topics that are split and does nothing to
> address WG size
> On Wed, Jul 23, 2014 at 4:18 PM, Loa Andersson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Alia,
>
>         tracking (and feel free to add agreement/support/__disagreement).
>
>         http://wiki.tools.ietf.org/__area/rtg/trac/wiki/__RtgCrossWGMailingLists
>         <http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgCrossWGMailingLists>
>
>         Alia
>
>
>
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              Along the lines of your second point we could experiment
>         with an OAM
>              mail
>              list. It'd be great if we could schedule the presentations
>         (assuming
>              they
>         <mailto:[email-masked]>
>              <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>               >That said, let's find a way to coordinate OAM across
>         groups, including
>               >BFD.
>               >
>               >In my discussions with Alia, I'm fond of the idea of
>         "meta" WGs.
>               >Individual
>               >involving adding a third chair.  But as Brooks' book
>         tells us,
>              adding more
>               >place.  That could happen either in existing WG context
>         (preserve
>              WG work
>               >Frankly, the Monday night dinner we had with several of
>         our key BFD
>               >members
>               >which also included significant conversation about
>         relationships to
>               >non-BFD
>     <mailto:[email-masked]>
>     Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>     <tel:%2B46%20739%2081%2021%2064>
>
>

--

---

From: Alia Atlas <[email-masked]>
Date: Wed, 23 Jul 2014 16:36:32 -0400

Loa,

It is not a function of the number of people, but the dynamics of the
interactions between the people.
A group could have 50 people actively discussing one topic, 50 people with
about 10 per each of 5
topics, etc.

Silence and lack of willingness to comment, review, or actively participate
are bad signs.

I can't give you a mathematical relationship that pretends people are
wooden blocks that can
be arbitrarily stacked together.

Alia

---

From: Loa Andersson <[email-masked]>
Date: Wed, 23 Jul 2014 22:39:41 +0200

OK - fair enough, can you give a hint of which working groups you think
lack "focus" because of its size?

/Loa

On 2014-07-23 22:36, Alia Atlas wrote:
> A group could have 50 people actively discussing one topic, 50 people
> with about 10 per each of 5
> topics, etc.
>
> Silence and lack of willingness to comment, review, or actively
> participate are bad signs.
>
> On Wed, Jul 23, 2014 at 4:30 PM, Loa Andersson <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              Alia,
>
>                  useful.  I am in favor of interest-based mailing lists.
>           Another
>                  case is
>                  tracking (and feel free to add
>         agreement/support/____disagreement).
>
>         http://wiki.tools.ietf.org/____area/rtg/trac/wiki/____RtgCrossWGMailingLists
>         <http://wiki.tools.ietf.org/__area/rtg/trac/wiki/__RtgCrossWGMailingLists>
>
>
>         <http://wiki.tools.ietf.org/__area/rtg/trac/wiki/__RtgCrossWGMailingLists
>         <http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgCrossWGMailingLists>>
>
>                  Alia
>
>
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>
>                       Sounds like a good idea to me.  Ops is about to
>         charter a
>                       centralized OAM
>                       On 7/23/14 10:48 AM, "Jeffrey Haas"
>         <[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>
>                       <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>
>                        >On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa
>         Andersson
>                  wrote:
>                        >partially apportioned based on not overloading
>         any given
>                  function or
>                        >individual.  This was part of my comment about
>         such a
>                  merger likely
>                        >people simply may make late work later - simply
>         due to
>                  the need for
>                        >be serviced by targeted presentation of related
>         work in
>                  an appropriate
>              Loa Andersson                        email:
>         [email-masked] <mailto:[email-masked]>
>              <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>              Huawei Technologies (consultant)     phone: +46 739 81 21
>         64 <tel:%2B46%20739%2081%2021%2064>
>              <tel:%2B46%20739%2081%2021%__2064>
>
>
>
>     --
>
>

--

---

From: Mach Chen <[email-masked]>
Date: Wed, 23 Jul 2014 20:43:47 +0000

Hi Loa,

> Though I'm totally supportive of some well considered re-organization of
> working groups, but
> 
> - do it carefully

I agree with this, and I would like to add one, when plan to re-org a WG, it should be clear what problems are going to be solved and what improvements are desired.

Best regards,
Mach

> Sent: Wednesday, July 23, 2014 6:49 AM
> Subject: [RTG-DIR] what is so bad
> 
> Folks,
> 
> The spread sheet list the number of RFC's per working group between two
> meeting. I've used the number of people who signed the blue sheets in
> Vancouver as some type of average except for roll that did not meet in
> Vancouver, where I used the London figure instead.
> 
> participants is exposed too, I don't think the a re-org is motivated by the figures
> in the spread sheet.
> 
> Though I'm totally supportive of some well considered re-organization of
> working groups, but
> 
> - do it carefully