IETF Operations Area Generic subjects

headers Romascanu, Dan (Dan | 3 Feb 2010 10:27 · /ever/

We have requested a two hours slot for the OPSAREA meeting in Anaheim.
Please send your proposals for items that you would like to be discussed
in the meeting. 

Thanks and Regards,

Ron and Dan

For folks who are not aware, a set of wikipages on the outcomes of the
IETF work, successes and failures was started at
http://trac.tools.ietf.org/misc/outcomes/ with per areas views that
include OPS -
http://trac.tools.ietf.org/misc/outcomes/wiki/IetfOperations 

The wiki is out there to be discussed and improved. Maybe it's a good
item to discuss shortly also in the OPSAREA meeting at IETF77. 

Dan

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

On 2/7/2010 3:26 AM, Bert Wijnen (IETF) wrote:
> Wow... sofar that does not look so good for the OPS area.
> Only a couple of protocols that we did in the late 80s (so even before I
> participated... or maybe just because of that ) seem to have good
> adoption.

For the initial version of the wiki, we did not try to be complete and we were 
not all that systematic.  It was a case of what examples some of us thought of. 
The most interesting choices were ones tested the limits of the wiki's template 
format, so we could consider enhancements to the form of the wiki.

As Dan's notes suggests, the nice thing about a wiki is that any of you (with an 
IETF tools login) can add to it or fix errors.

Please do!

d/
--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Hi,

I think this results table an interesting idea, but I have some
concerns.

1) My first concern is about the clarity of adoption ratings.
SNMPv1 was obviously widely adopted. 
But a recent survey shared by Bert showed 14% using SNMPv1, 65% using
SNMPv2, and 12% using SNMPv3. Yet SNMPv1 is listed as massive
adoption, SNMPv2 is listed as some adoption, and SNMPv3 as complete
failure. 

Obviously, the adoption rates in the table differ from the survey
results quite a bit. Whose measurements should we use to declare
adoption rates?

If 12% adoption is complete failure, how do we score something like
SNMPCONF, or the EOS or SMING efforts?

2) I have concerns about IETF Origin.
IPFIX is classified as IETF Origin, but the ipfix WG actually started
when companies contributed their proprietary flow accounting protocol
designs, combined with requests from flow accounting users, to develop
a standard. IPFIX is very largely based on Netflow (chosen after a
bakeoff), coupled with a TCP transport based on Cabletron's
lightweight flow accounting protocol, and features from SFLOW(?), and
elements of CRANE from (NetApp?). And it built atop aspects of the
IETF RTFM standard. 

ipfix did not start out as an IETF design; I think an analysis of IPR
disclosures would certainly reflect that; the ipfix WG just developed
existing work into a standard. 

What criteria should be used for this binary decision?

3) I have concerns about whether "adoption" is historical adoption or
current adoption.
At what point in time is adoption measured? Is netconf a complete
failure because it has not been widely adopted yet? Was SNMPv1
massively adopted in 1990? Maybe the chart should have adoption
ratings at 2 years, 5 years, 10 years, and 15+ to get a better idea of
adoption trends. 

SNMPv3 is judged as a complete failure, but it has far more adoption
than netconf at this point. We certainly do not want to discourage
people from adopting Netconf because so far it has not achieved
massive adoption. Yet this chart could do that if the timeline of
availability versus adoption isn't represented.

4) I have concerns about "adoption" when it relates to extensions
versus the base technology. SNMPv2 and SNMPv3 build upon the base SNMP
design. What has been adopted widely in SNMPv2? Is it the operations
(getBulk), or is it SMIv2 extensions (Counter64)? 

SNMPv2 added very little to SNMPv1; SNMPv3 added a huge number of
extensions, with new varbind formats, different transports, detailed
authentication and integrity checking, per-user authorizations,
standardized notification configurations, proxy, etc. The costs
associated with adopting a huge extension compared to a small
extension is not reflected in the table. Yet certainly that has an
impact on adoption.

SNMPv2 and SNMPv3 still use the base protocol features, such as GETs
and SETs, traps and request/responses, and so on. That doesn't really
get reflected in this table. 

MIB-2 achieved wide adoption, but many later MIB modules achieved much
less adoption.

I notice Diameter is listed as a separate protocol from RADIUS, but
isn't Diameter really RADIUS v2? Diameter has been adopted by the
telecom/service provider segment, but it has been largely rejected by
the enterprise segment who prefer the simplicity of RADIUS. But
adoption by some market segements and not others certainly doesn't get
reflected in this table.

I would be interested in seeing the adoption trends for other
protocols and later versions or their extensions, like DHCP and TLS
and RADIUS and ipfix and IPv4/IPv6. I suspect the massively adopted
protocols really solve massive basic operational problems, whereas
extensions to those protocols solve problems with dramatically less
operational demand, because the base protocol already solved most of
the problem.

5) I am concerned about incomplete information, especially concerning
area production. 

Bert's response was "wow. we haven't achieved much". But we haven't
listed most of the work that has occurred in the OPS area. Where is
SMIv1, SMIv2, MIB-2, and all the MIB modules that have been massively
adopted? The bulk of the work done in the OPS area since 1990 has
probably been MIB module development. Where is capwap, disman,
snmpconf, eos, sming, and a wide range of others? If people, even
Bert, look at this and think it is in any way a reflection of what OPS
has contributed to the IETF in the last ten years, then this table is
highly misleading.

6) I am concerned about statistics without analysis. The info
presented has no analysis with it. I think it could be tremedously
useful to understand that, as documented in rfc 1052, the SNMP suite
started with a cintributed data modeling language (which became SMIv1)
and a common information model (which became the MIB), then added two
protocols - one long-term (CMIP) and one a simple, temporary protocol
to use until the long-term protocol was ready (SNMP). I believe the
SNMP suite achieved fairly quick adoption because of its relative
simplicity, but also because MIB-1 and MIB-2 defined a standard
information model so there was something to actually manage - and it
was relatively simple, providing counters for things like packets in
and packets out for core protocols like IP, UDP, TCP, etc. 

I am especially concerned because I see many efforts that try to build
the pieces separately. For example, netconf was published two years
ago, but the data modeling language is still in development, and there
are no manageable data models available. Sip-clf is trying to build
just a data model without considering how protocols will need to work
to acheive the targeted use cases (and what effect that will have on
the information and data models).

--Summary--

I think this results chart is way too simplistic, and it can be very
misleading, and it could lead to bad decisions about how we should
develop protocols.

David Harrington
dbharrington <at> comcast.net
ietfdbh <at> comcast.net
dharrington <at> huawei.com

> -----Original Message-----
> From: ops-area-bounces <at> ietf.org 
> [mailto:ops-area-bounces <at> ietf.org] On Behalf Of Romascanu, Dan (Dan)
> Sent: Sunday, February 07, 2010 3:41 AM
> To: ops-area <at> ietf.org
> Cc: ops-chairs <at> ietf.org
> Subject: [OPS-AREA] IETF Outcomes wiki
> 
> For folks who are not aware, a set of wikipages on the outcomes of
the
> IETF work, successes and failures was started at
> http://trac.tools.ietf.org/misc/outcomes/ with per areas views that
> include OPS -
> http://trac.tools.ietf.org/misc/outcomes/wiki/IetfOperations 
> 
> The wiki is out there to be discussed and improved. Maybe it's a
good
> item to discuss shortly also in the OPSAREA meeting at IETF77. 
> 
> Dan
> _______________________________________________
> OPS-AREA mailing list
> OPS-AREA <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ops-area
> 

As I understand this - it's a wiki - so it's open for comments (as any
IETF work) and it's open for additions and corrections. 

I have two comments to yours (to which I agree to a large extent): 

- when talking about adoption, there is a certain period of time before
any judgment can be made. This may differ from area to area and from
types of protocols to other. For management protocols I think that the
level of adoption can be measured only after the basic pieces of the
management framework for the protocol are in place - these includes the
protocol itself and the associated data modeling language and security
framework. Of course, if any of these three elements is too late in
showing up the protocol can be declared a failure, but happens only
after a while. For NETCONF I believe we are in the situation that it's
far too early to make a judgment, as the work for its associated DML is
still in progress
- there are certainly many elements missing in the table, and I see this
only as a starting point, maybe intentionally filled in only with a few
rows to ignite discussion and invite the OPS community to contribute to
it filling the empty spaces. I would certainly add SMI and SMIv2 as
separate entries. 

I agree about your observation concerning the DNA of IPFIX. On the other
hand I think that the later evolution shows that the industry did not
buy the Diameter is RADIUSv2 concept.

Dan

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh <at> comcast.net] 
> Sent: Sunday, February 07, 2010 6:09 PM
> To: Romascanu, Dan (Dan); ops-area <at> ietf.org
> Cc: ops-chairs <at> ietf.org; ietf-outcomes <at> ietf.org
> Subject: RE: [OPS-AREA] IETF Outcomes wiki
> 
> Hi,
> 
> I think this results table an interesting idea, but I have 
> some concerns.
> 
> 1) My first concern is about the clarity of adoption ratings.
> SNMPv1 was obviously widely adopted. 
> But a recent survey shared by Bert showed 14% using SNMPv1, 
> 65% using SNMPv2, and 12% using SNMPv3. Yet SNMPv1 is listed 
> as massive adoption, SNMPv2 is listed as some adoption, and 
> SNMPv3 as complete failure. 
> 
> Obviously, the adoption rates in the table differ from the 
> survey results quite a bit. Whose measurements should we use 
> to declare adoption rates?
> 
> If 12% adoption is complete failure, how do we score 
> something like SNMPCONF, or the EOS or SMING efforts?
> 
> 2) I have concerns about IETF Origin.
> IPFIX is classified as IETF Origin, but the ipfix WG actually 
> started when companies contributed their proprietary flow 
> accounting protocol designs, combined with requests from flow 
> accounting users, to develop a standard. IPFIX is very 
> largely based on Netflow (chosen after a bakeoff), coupled 
> with a TCP transport based on Cabletron's lightweight flow 
> accounting protocol, and features from SFLOW(?), and elements 
> of CRANE from (NetApp?). And it built atop aspects of the 
> IETF RTFM standard. 
> 
> ipfix did not start out as an IETF design; I think an 
> analysis of IPR disclosures would certainly reflect that; the 
> ipfix WG just developed existing work into a standard. 
> 
> What criteria should be used for this binary decision?
> 
> 3) I have concerns about whether "adoption" is historical 
> adoption or current adoption.
> At what point in time is adoption measured? Is netconf a 
> complete failure because it has not been widely adopted yet? 
> Was SNMPv1 massively adopted in 1990? Maybe the chart should 
> have adoption ratings at 2 years, 5 years, 10 years, and 15+ 
> to get a better idea of adoption trends. 
> 
> SNMPv3 is judged as a complete failure, but it has far more 
> adoption than netconf at this point. We certainly do not want 
> to discourage people from adopting Netconf because so far it 
> has not achieved massive adoption. Yet this chart could do 
> that if the timeline of availability versus adoption isn't 
> represented.
> 
> 4) I have concerns about "adoption" when it relates to 
> extensions versus the base technology. SNMPv2 and SNMPv3 
> build upon the base SNMP design. What has been adopted widely 
> in SNMPv2? Is it the operations (getBulk), or is it SMIv2 
> extensions (Counter64)? 
> 
> SNMPv2 added very little to SNMPv1; SNMPv3 added a huge 
> number of extensions, with new varbind formats, different 
> transports, detailed authentication and integrity checking, 
> per-user authorizations, standardized notification 
> configurations, proxy, etc. The costs associated with 
> adopting a huge extension compared to a small extension is 
> not reflected in the table. Yet certainly that has an impact 
> on adoption.
> 
> SNMPv2 and SNMPv3 still use the base protocol features, such 
> as GETs and SETs, traps and request/responses, and so on. 
> That doesn't really get reflected in this table. 
> 
> MIB-2 achieved wide adoption, but many later MIB modules 
> achieved much less adoption.
> 
> I notice Diameter is listed as a separate protocol from 
> RADIUS, but isn't Diameter really RADIUS v2? Diameter has 
> been adopted by the telecom/service provider segment, but it 
> has been largely rejected by the enterprise segment who 
> prefer the simplicity of RADIUS. But adoption by some market 
> segements and not others certainly doesn't get reflected in 
> this table.
> 
> I would be interested in seeing the adoption trends for other 
> protocols and later versions or their extensions, like DHCP 
> and TLS and RADIUS and ipfix and IPv4/IPv6. I suspect the 
> massively adopted protocols really solve massive basic 
> operational problems, whereas extensions to those protocols 
> solve problems with dramatically less operational demand, 
> because the base protocol already solved most of the problem.
> 
> 5) I am concerned about incomplete information, especially 
> concerning area production. 
> 
> Bert's response was "wow. we haven't achieved much". But we 
> haven't listed most of the work that has occurred in the OPS 
> area. Where is SMIv1, SMIv2, MIB-2, and all the MIB modules 
> that have been massively adopted? The bulk of the work done 
> in the OPS area since 1990 has probably been MIB module 
> development. Where is capwap, disman, snmpconf, eos, sming, 
> and a wide range of others? If people, even Bert, look at 
> this and think it is in any way a reflection of what OPS has 
> contributed to the IETF in the last ten years, then this 
> table is highly misleading.
> 
> 6) I am concerned about statistics without analysis. The info 
> presented has no analysis with it. I think it could be 
> tremedously useful to understand that, as documented in rfc 
> 1052, the SNMP suite started with a cintributed data modeling 
> language (which became SMIv1) and a common information model 
> (which became the MIB), then added two protocols - one 
> long-term (CMIP) and one a simple, temporary protocol to use 
> until the long-term protocol was ready (SNMP). I believe the 
> SNMP suite achieved fairly quick adoption because of its 
> relative simplicity, but also because MIB-1 and MIB-2 defined 
> a standard information model so there was something to 
> actually manage - and it was relatively simple, providing 
> counters for things like packets in and packets out for core 
> protocols like IP, UDP, TCP, etc. 
> 
> I am especially concerned because I see many efforts that try 
> to build the pieces separately. For example, netconf was 
> published two years ago, but the data modeling language is 
> still in development, and there are no manageable data models 
> available. Sip-clf is trying to build just a data model 
> without considering how protocols will need to work to 
> acheive the targeted use cases (and what effect that will 
> have on the information and data models).
> 
> --Summary--
> 
> I think this results chart is way too simplistic, and it can 
> be very misleading, and it could lead to bad decisions about 
> how we should develop protocols.
> 
> David Harrington
> dbharrington <at> comcast.net
> ietfdbh <at> comcast.net
> dharrington <at> huawei.com
> 
> 
> > -----Original Message-----
> > From: ops-area-bounces <at> ietf.org
> > [mailto:ops-area-bounces <at> ietf.org] On Behalf Of Romascanu, Dan (Dan)
> > Sent: Sunday, February 07, 2010 3:41 AM
> > To: ops-area <at> ietf.org
> > Cc: ops-chairs <at> ietf.org
> > Subject: [OPS-AREA] IETF Outcomes wiki
> > 
> > For folks who are not aware, a set of wikipages on the outcomes of
> the
> > IETF work, successes and failures was started at 
> > http://trac.tools.ietf.org/misc/outcomes/ with per areas views that 
> > include OPS - 
> > http://trac.tools.ietf.org/misc/outcomes/wiki/IetfOperations
> > 
> > The wiki is out there to be discussed and improved. Maybe it's a
> good
> > item to discuss shortly also in the OPSAREA meeting at IETF77. 
> > 
> > Dan
> > _______________________________________________
> > OPS-AREA mailing list
> > OPS-AREA <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/ops-area
> > 
> 
> 

My response to David's focus' on his concerns ab out the nature of the wiki, 
rather than about ops-specific issues. So I've posted my reply on the 
ietf-outcomes mailing list and suggest that any discussion take place there:

    <http://www.ietf.org/mail-archive/web/ietf-outcomes>

d/

-------- Original Message --------
Subject: Re: [ietf-outcomes] [OPS-AREA] IETF Outcomes wiki
Date: Sun, 07 Feb 2010 10:00:17 -0800
From: Dave CROCKER <dhc <at> dcrocker.net>
Reply-To: dcrocker <at> bbiw.net
Organization: Brandenburg InternetWorking
To: David Harrington <ietfdbh <at> comcast.net>
CC: ietf-outcomes <at> ietf.org, ops-chairs <at> ietf.org, ops-area <at> ietf.org

Dave,

Thoughtful posting.  Thanks!

Responding only to the larger issues you raise (but hoping others will also
discuss the detail)...

On 2/7/2010 8:08 AM, David Harrington wrote:
> Hi,
>
> I think this results table an interesting idea, but I have some
> concerns.
>
> 1) My first concern is about the clarity of adoption ratings.
> SNMPv1 was obviously widely adopted.
> But a recent survey shared by Bert showed 14% using SNMPv1, 65% using
> SNMPv2, and 12% using SNMPv3. Yet SNMPv1 is listed as massive
> adoption, SNMPv2 is listed as some adoption, and SNMPv3 as complete
> failure.

The rating is like a 'best achieved' meter.  It pegs at the best value /ever/
achieved.  It's not designed to show reduced use over time.

Perhaps another column should be added, to distinguish between "best" and
"current"?  (Although that creates a serious challenge, for keeping the
'current' value, ummmmm... current.)

SNMPv1 was certainly massively successful... in its day.

> ipfix did not start out as an IETF design; I think an analysis of IPR
> disclosures would certainly reflect that; the ipfix WG just developed
> existing work into a standard.
>
> What criteria should be used for this binary decision?

Kernigan or Ritche defined "portable code" as needing less than 10% re-writing.
  Perhaps some similarly pragmatic definition should be developed for
determining whether something started "within" the IETF?

Since everything we define incorporates some details from outside, the right
choice here is probably something along the lines of "the ietf assembled or
invented all the pieces" vs. "the ietf made some changes to a pre-existing
spec".  But I'm just guessing.

> 3) I have concerns about whether "adoption" is historical adoption or
> current adoption.
> At what point in time is adoption measured? Is netconf a complete
> failure because it has not been widely adopted yet? Was SNMPv1
> massively adopted in 1990? Maybe the chart should have adoption
> ratings at 2 years, 5 years, 10 years, and 15+ to get a better idea of
> adoption trends.

You are raising a question that is clearly reasonable.  I don't know what my own
opinion about the particulars of the answer is.

However the one caution I will suggest is against trying to make this wiki
assert much "precision".  The method for developing entries is highly
subjective, and that means precision is extremely coarse.  It will be misleading
to represent more precision about community rough consensus than is warranted.

There is a natural tendency to want finer-grained resolution to information, but
we typically are not going to have assessment techniques that justify them, nor
will we find a compelling community /need/ for the effort to develop them.

To be pedantic about the precisions limitations when reporting assessment:  for
empirical efforts like this, the answer to 1.5 * 1.7 is not 2.55.  It's 2.6.

>       We certainly do not want to discourage
> people from adopting Netconf because so far it has not achieved
> massive adoption. Yet this chart could do that if the timeline of
> availability versus adoption isn't represented.

This is an interesting point:  To what extent can entries in this table
influence the use of the things being listed?

I had assumed that an assessment should only be listed after the value to use
(degree of success or failure) was quite clear to the community and that there
therefore was/is consensus about it.  Other than the "0" value (still pending),
of course.  I guess I could also imagine going from + to ++, or ++ to ++>, over
time.

> 4) I have concerns about "adoption" when it relates to extensions
> versus the base technology. SNMPv2 and SNMPv3 build upon the base SNMP
> design. What has been adopted widely in SNMPv2? Is it the operations
> (getBulk), or is it SMIv2 extensions (Counter64)?
...
> SNMPv2 and SNMPv3 still use the base protocol features, such as GETs
> and SETs, traps and request/responses, and so on. That doesn't really
> get reflected in this table.

Not sure what sort of "reflected" you are looking for.

Please note that the table is attempting to report on the utility of particular
a standards effort, not necessarily the functional relationship among different
effort.

That is, the bald form of the question is:  Was the incremental effort to
produce SNMPv2 worth the considerable effort?  Every standards effort is
enormously expensive.  Try calculating the aggregate cost of participant time
for even the smallest effort; it's intimidating.

(However Jon Callas commented to me that some efforts that are overtly a failure
do provide valuable learning for later efforts that succeed; and indeed,
capturing this is part of the goal in the "phases" idea, for efforts that have
to change direction.)

> I notice Diameter is listed as a separate protocol from RADIUS, but
> isn't Diameter really RADIUS v2?

This gets back to the notation question I raised separately, for such things as
phases.  It would be great if we could resolve this to cover such cases.

And this particular example can't reasonably be supported by the choice I had
stated a preference for, which is a version number in column 1, since the basic
name is different.

>  Diameter has been adopted by the
> telecom/service provider segment, but it has been largely rejected by
> the enterprise segment who prefer the simplicity of RADIUS. But
> adoption by some market segements and not others certainly doesn't get
> reflected in this table.

That's where the Target/Segment column helps.

> I would be interested in seeing the adoption trends for other
> protocols and later versions or their extensions, like DHCP and TLS
> and RADIUS and ipfix and IPv4/IPv6.

+1.

> 5) I am concerned about incomplete information, especially concerning
> area production.

The good news, is that you can directly remedy that deficiency....

> 6) I am concerned about statistics without analysis. The info
> presented has no analysis with it.

The right-most column is conveniently available for pointing to in-depth
information...  Discussion of history, core issues, and the like, is not the
goal of this wiki, but yes, it could be extremely helpful to develop that
information.

> I am especially concerned because I see many efforts that try to build
> the pieces separately. For example, netconf was published two years
> ago, but the data modeling language is still in development, and there
> are no manageable data models available. Sip-clf is trying to build
> just a data model without considering how protocols will need to work
> to acheive the targeted use cases (and what effect that will have on
> the information and data models).

Is there a way to depict this sort of issue in a table?  Can the wiki be
modified to support it?

> --Summary--
>
> I think this results chart is way too simplistic, and it can be very
> misleading, and it could lead to bad decisions about how we should
> develop protocols.

Your premise is that greater complexity will produce greater insight.

The cognitive reality is that there needs to be a balance between simplicity and
complexity.  Go too far in either direction and utility is lost.

Where the balance needs to be largely depends on the details of the target
population for consuming the wiki data.

d/
--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
ietf-outcomes mailing list
ietf-outcomes <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-outcomes

_______________________________________________
OPS-AREA mailing list
OPS-AREA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28

1	May 2013
2	April 2013
10	March 2013
7	January 2013
2	November 2012
4	October 2012
29	August 2012
4	July 2012
5	June 2012
29	May 2012
10	April 2012
16	March 2012
4	February 2012
2	January 2012
2	December 2011
6	November 2011
13	October 2011
1	August 2011
4	July 2011
3	June 2011
2	May 2011
3	April 2011
7	March 2011
5	February 2011
3	January 2011
1	December 2010
98	November 2010
6	October 2010
20	September 2010
4	August 2010
11	July 2010
17	June 2010
1	May 2010
1	April 2010
12	March 2010
44	February 2010
2	January 2010
19	December 2009
4	November 2009
3	October 2009
25	September 2009
3	August 2009
17	July 2009
8	June 2009
5	May 2009
6	April 2009
13	March 2009
20	February 2009
4	January 2009
8	December 2008
4	November 2008
4	October 2008
16	September 2008
17	August 2008
19	July 2008
16	June 2008
13	May 2008
5	April 2008
17	March 2008
13	February 2008
6	January 2008
21	December 2007
17	November 2007
31	October 2007
13	September 2007
6	August 2007
9	July 2007
36	June 2007
29	May 2007
23	April 2007
71	March 2007
17	February 2007
32	January 2007
15	December 2006
21	November 2006
13	October 2006
2	September 2006
3	August 2006
6	July 2006
1	February 2006
1	January 2006
6	November 2005
1	October 2005
1	January 2005
1	December 2004
15	November 2004
1	October 2004
4	June 2004
2	March 2004
1	February 2004
12	January 2004
1	October 2003
14	September 2003
1	August 2003
2	July 2003
3	April 2003
4	March 2003
3	February 2003
1	December 2002
1	October 2002
3	July 2002

Agenda Items for the OPSAREA Meeting in Anaheim

IETF Outcomes wiki

Fw: IETF Outcomes wiki

Re: IETF Outcomes wiki

Re: Fw: IETF Outcomes wiki

Re: Fw: IETF Outcomes wiki

Re: IETF Outcomes wiki

Re: IETF Outcomes wiki

Fwd: Re: [ietf-outcomes] IETF Outcomes wiki

Re: Fw: IETF Outcomes wiki