Subject: [OPS-AREA] IETF Outcomes wiki

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Feb 2010 09:41:29 +0100

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

---

From: "Bert Wijnen" <[email-masked]>
Date: Sun, 7 Feb 2010 11:55:51 +0100

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.

Bert
  ----- Original Message ----- 
  From: Romascanu, Dan (Dan) 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Sunday, February 07, 2010 9:41 AM
  Subject: IETF Outcomes wiki

  Dan

------------------------------------------------------------------------------

  Geen virus gevonden in het binnenkomende-bericht.
  Gecontroleerd door AVG - www.avg.com 
  Versie: 9.0.733 / Virusdatabase: 271.1.1/2672 - datum van uitgifte: 02/06/10 20:35:00

---

From: "David Harrington" <[email-masked]>
Date: Sun, 7 Feb 2010 11:08:58 -0500

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
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Sunday, February 07, 2010 3:41 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [OPS-AREA] IETF Outcomes wiki
> 
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Feb 2010 17:51:36 +0100

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

> From: David Harrington [mailto:[email-masked]] 
> Sent: Sunday, February 07, 2010 6:09 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [OPS-AREA] IETF Outcomes wiki
> 
> Hi,
> 
> I think this results table an interesting idea, but I have 
> some concerns.
> 
> 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?
> 
> 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. 
> 
> 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.
> 
> 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.
> 
> 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
> [email-masked]
> [email-masked]
> [email-masked]
> 
>

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 7 Feb 2010 23:26:50 +0100

Dave...
  ----- Original Message ----- 
  From: David Harrington 
  To: 'Romascanu, Dan (Dan)' ; [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Sunday, February 07, 2010 5:08 PM
  Subject: Re: [OPS-AREA] IETF Outcomes wiki

  Hi,

  Bert's response was "wow. we haven't achieved much".

I hope (assume/assumed) that you understand that I certainly also do not agree with
what is currently listed on the OPS outcomes page.

It is just that if you read that page.... one would have to come to that conclusion.

Bert

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 8 Feb 2010 13:01:16 -0800

Regarding:

a) http://trac.tools.ietf.org/misc/outcomes/wiki/IetfOperations
Need a legend for the values in the Adoption column no?

b) I don't see how one can compare the 80s to the 90s though, its not quite fair comparison.
I see percentages floating about but didn't see where are the absolute numbers in any of the links on trac.
I would have preferred to see numeric tables  as the overall pie's growth was 
nothing short of spectacular for those decades.

c) Think the SMI should be broken out of SNMP and given its due.
That we have for the large set pf core mib modules: (mib-2 and its progeny, host-resources, entity,
some parts of rmon, and spawned a bazillion enterprise trap notifications), 
it remains how systems are widely monitored for fault/performance 
(but not configured).  A resounding success to me.

Add to that other standards orgs like IEEE that use or used to (not sure current state) define SMI mib modules
for technologies it develops, so then some credit is due to  SMI itself outside of the SNMP protocol. Modulo
some protocol limitations SMI has done quite well.  How's this for the sincerest form of flattery:
http://www.vmware.com/support/developer/cim-sdk/smash/u2/ga/apirefdoc/CIM_EthernetPortStatistics.html

Mike MacFaden

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Bert Wijnen [[email-masked]]
Sent: Sunday, February 07, 2010 2:55 AM
To: Romascanu, Dan (Dan); [email-masked]
Cc: [email-masked]
Subject: Re: [OPS-AREA] IETF Outcomes wiki

Bert
----- Original Message -----
From: Romascanu, Dan (Dan)<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Sent: Sunday, February 07, 2010 9:41 AM
Subject: IETF Outcomes wiki

Dan

________________________________

Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com<http://www.avg.com>
Versie: 9.0.733 / Virusdatabase: 271.1.1/2672 - datum van uitgifte: 02/06/10 20:35:00

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 08 Feb 2010 15:14:45 -0800

On 2/8/2010 1:01 PM, Michael MacFaden wrote:
> a) http://trac.tools.ietf.org/misc/outcomes/wiki/IetfOperations Need a legend
> for the values in the Adoption column no?

How about:

    <http://trac.tools.ietf.org/misc/outcomes/#Legend>

Come to think of it, the point ought to be on each page.  So I've added it.

> b) I don't see how one can compare the 80s to the 90s though, its not quite
> fair comparison. I see percentages floating about but didn't see where are
> the absolute numbers in any of the links on trac. I would have preferred to
> see numeric tables  as the overall pie's growth was nothing short of
> spectacular for those decades.

You want an empirical study with diligent methodology.  That would be nice, but
this is explicitly not that.

This is a rough consensus of subjective assessment.

In terms of assessing IETF productivity, the fact that something was a a huge
success is frankly more important than how large the market was.  What matters 
is that the IETF produced something that became popular.

The sort of adjustment based on age or market size could provide other sorts of 
useful insight, but the keyword is 'other'.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "David Harrington" <[email-masked]>
Date: Mon, 8 Feb 2010 18:39:42 -0500

Hi,

I wonder if "adoption" might not be broken into two parts, comparable
to the RFC2026 standards track:
implementations versus deployment.

Some standards, like BEEP or SCRIPT-MIB, never got much
implementation, so couldn't be deployed.
Others, like SNMPv3, have some implementation, but still don't get
deployed because they require too much work to configure.

dbh

> [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Monday, February 08, 2010 6:15 PM
> To: Michael MacFaden
> Cc: [email-masked]
> > a) 
> Need a legend

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 8 Feb 2010 15:58:08 -0800

>Come to think of it, the point ought to be on each page.  So I've added it.

Nice. thanks.

>useful insight, but the keyword is 'other'.

Good to know, would be useful to update the legend with how the values
were/are being defined. 

If the size  or kind of market isn't defined in the table, then
the subjective value given is even less useful  to come to a common understanding.

ie What part of the elephant are you touching anyway?

afaik,  SNMPv3 has 100% adoption (nay popular) rate in [Euro-]DOCSIS 
based cable modem market, something less in US Gov't/Federal markets, and 
tiny in enterprise markets. Financial markets being the one wanting better
security.

Mike  MacFaden

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 08 Feb 2010 17:06:00 -0800

> Good to know, would be useful to update the legend with how the values

Reasonable idea.  I look forward to your wordsmithing...

> the subjective value given is even less useful  to come to a common understanding.

That depends on what understanding is being sought.

The community might decide to take the wiki in the direction you have in mind, 
but the 'understanding' that motivated my developing the wiski was simply "what 
succeeded?"  The answer to that question does not depend on market size, nor the 
year of the success.

Since you are being tenacious about the importance of the size of the market in 
which the success take place, I'll ask you to elaborate:  How does it matter? 
Specifically, what should the IETF learn from that distinction, about the 
utility of its work or how it should do things differently?

> tiny in enterprise markets. Financial markets being the one wanting better

Ahhh.  That's not about market size or year.  That's about the /type/ of market 
and its a distinction that led to the Target Segment column.

Your observation suggests that there is perhaps a different value, depending on 
the Target Segment.  Looks like perhaps ++ for DOCSIS and maybe Gov't, and - in 
Enterprise.

First question is whether those differential values match other people's assessment?

Second is whether they want the wiki to differentiate this, and why that's 
important.

Third, is what annotation should be used, to indicate differential success?

But this really is a topic for the Outcomes list.  Can we move this over there?

d/

--

   Dave Crocker

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 08 Feb 2010 21:48:11 -0800

> It is just that if you read that page.... one would have to come to that

One might also conclude that appart from some rather obvious successes,
that attempting to determine if something is a success or failure as
part of the outcomes exercise is a fools errand. Although as with many
IETF exercises if enough fools work hard enough you might luck out and
end up with something useful.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 8 Feb 2010 22:46:58 -0800

I'd argue that the wiki is not using the same definition of "success" that we used in RFC 5218. 

If the data shows that 85 percent of the original implementers of SNMPv1 went on to implement
SNMPv2 at some point, then if SNMPv1 was a success under the RFC 5218 criteria, then SNMPv2
would also have to be judged a success. 

In fact, using the RFC 5218 criteria, SNMPv1/v2 might also be judged as a "wild success"
in that it was used more widely and for things beyond what the creators envisaged. 

Note that the RFC 5218 criteria explicitly include the original scope in the definition of
"success".  For example, if a protocol was deployed for its original purpose in the originally
envisaged use, that is success. 

So a protocol such as Kerberos can be judged a "success" even though it is not used in
consumer scenarios in the same manner as say, SSL/TLS.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Feb 2010 07:10:48 -0800

please, can we move this thread to the Outcomes list?

You guys are posting interesting stuff.

d/

-- 

   Dave Crocker

---

From: "David Harrington" <[email-masked]>
Date: Tue, 9 Feb 2010 10:53:11 -0500

Hi,

I think it would be good to set success and failure to match rfc 5218,
and have the legends page provide brief descriptions of the
categories, and reference RFC 5218 for more details.

dbh

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, February 09, 2010 1:47 AM
> To: 'Joel Jaeggli'; 'Bert Wijnen (IETF)'
> Cc: 'David Harrington'; 'Romascanu, Dan (Dan)'; 'ops-area 
> (IETF)'; [email-masked]
> If the data shows that 85 percent of the original 
> implementers of SNMPv1 went on to implement
> > I hope (assume/assumed) that you understand that I 
> certainly also do not
> > agree with
> > It is just that if you read that page.... one would have to 
> come to that
> > conclusion.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Feb 2010 17:08:51 +0100

> You guys are posting interesting stuff.

I only have one question: What is the process to create wiki pages on
the IETF site? I think I have some more cool wiki page ideas I like to
post on the IETF site and I am ready to create mailing lists for
people to join to discuss interesting stuff about the cool pages I
have created.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Feb 2010 08:23:57 -0800

> I think it would be good to set success and failure to match rfc 5218,

My reply went to the ietf-outcomes list.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Feb 2010 09:01:09 -0800

I approached the IETF Chair, who passed me to the IAB Chair, who passed me to 
the person on the IAB with some history in related work (Dave Thaler) who spent 
the next six months first asking the IAB if there were objections and then the 
IESG.

I hadn't heard back so I pressed a few times and finally was told there were no 
objections, and that the IETF Chair needed to authorize moving the wiki to the 
onto the site.  I queried the IETF Chair and we had it installed within 2 days 
after that.  (Henrik Levkowetz was the tools site contact and he's a very 
responsive guy!)

Note that the wiki already had a history and a small-but-real base of support. 
  I remain a fan of building a base of work and support, before worrying about 
going through the formalities.  It makes things much more concrete and 
demonstrates some degree of market validation.

d/

-- 

   Dave Crocker

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 9 Feb 2010 12:28:04 -0800

Dave Crocker said:

"This means that a protocol is a failure if it is widely used, but for
different 
purposes than it was intended."

[BA] If a protocol has been implemented, deployed and used, I don't think
that 
can qualify as a failure under the RFC 5218 definition. From 
Section 1.4:

"   Failure, or the lack of success, cannot be determined before allowing
   sufficient time to pass (e.g., 5-10 years for an average protocol).
   Failure criteria include:

   o  No mainstream implementations.  There is little or no support in
      hosts, routers, or other classes of relevant devices.

   o  No deployment.  Devices that support the protocol are not
      deployed, or if they are, then the protocol is not enabled.

   o  No use.  While the protocol may be deployed, there are no
      applications or scenarios that actually use the protocol."

Dave Crocker also said:

"Deployed" is also a problem, since there is a long track record of
industry's 
having deployed something but never actually using it very much.  I submit
all 
of OSI as a prime example.

These are the reasons the wiki was premised on the simple measure of use.

However I note that the column that lists degree of success only uses the
word 
'adoption'. However Target Segment uses 'use'."

[BA] I'd suggest that implementation, deployment and use are separate
stages,
worth documenting separately.  If that is done, we may learn 
something about the characteristics that affect success at each stage. 

One aspect that bothers me about use is the definition of each category. 

Surely if almost nobody uses something, it is a "--" failure (e.g. IPsec
AH). 
But what if the protocol is used by the people it is designed for, but not
the vast majority of humanity? 

I use Kerberos all the time, but most people probably don't.  What category
does
this fall in?  Probably not "++" or "++>", but not "--" either.  So we're
left
with "-" and "+".  How are these categories defined?

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Feb 2010 08:21:15 -0800

Dave,

> categories, and reference RFC 5218 for more details.

The easy question is:  why?

The definition in RFC 5218 is:

      "we consider a successful protocol to be one that both meets its original
      goals and is widely deployed."

This means that a protocol is a failure if it is widely used, but for different 
purposes than it was intended.

"Deployed" is also a problem, since there is a long track record of industry's 
having deployed something but never actually using it very much.  I submit all 
of OSI as a prime example.

However I note that the column that lists degree of success only uses the word 
'adoption'. However Target Segment uses 'use'.

d/

ps.  I also note you've been busy updating net management-related entries.  Thanks!

-- 

   Dave Crocker

---

From: Michael MacFaden <[email-masked]>
Date: Thu, 11 Feb 2010 10:52:35 -0800

To add to Fred's post, here was the discussion I saw on nanog list:
http://mailman.nanog.org/pipermail/nanog/2010-February/017900.html

Mike MacFaden

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Feb 2010 20:18:04 +0100

> http://mailman.nanog.org/pipermail/nanog/2010-February/017900.html

Lots of talk but I did not see what the technical issue is. Does
anyone have a pointer to technical information?

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 11 Feb 2010 14:26:57 -0500

http://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2
010-Cross-Attacking-LawfulI-Intercept-slides.pdf

dbh 

> [mailto:[email-masked]] On Behalf Of Juergen
Schoenwaelder
> Sent: Thursday, February 11, 2010 2:18 PM
> To: Michael MacFaden
> Cc: [email-masked]