Subject: Re: Not developing protocols

From: Vernon Schryver <[email-masked]>
Date: Sun, 11 Feb 2001 16:12:27 -0700 (MST)

> From: Ofer Inbar <[email-masked]>

> > "If farmers can be paid not to grow wheat, why can't IETF
> > WGs be paid not to develop protocols?"
>
> We can.  Just go work for a company that is willing to send you to
> IETF on their time & money, and wants you to disrupt certain IETF
> protocol work.  I'm sure many of us have witnessed this in action, and
> we've probably missed some of the more subtle and skilled efforts.  It
> most assuredly does happen.  My epiphany on this subject came during a
> session of the HTML 3.0 working group, circa 1994.  I don't think it's
> an accident that that WG effort did not produce a standard, although
> of course I can't prove anything about anyone's intent at the time.

The official dogma of every Standards Process is that the Process has
failed if it does not produce a document.  In real life, no document
is more often a success a failure.  On the other side of the coin, a
committee document is more often a failure than a success.  This side
is trivially proven for the IETF by referring to the RFC index.

Of course, every Standards Process defines producing any document as
success, while the real world defines standards success as first improving
interoperability and a distant second as advancing the state of the art.

Those of us with toeholds in the real world know that official standards
are as often used (and even intentionally) to harm as to help
interoperability.  100VG-AnyLAN is a classic case study of a painfully
obviously broken protocol flogged through a Standards Process to a de
jure standard when the technical and business situation was clear even
before the shenanigans that started the IEEE 802 subcommittee (e.g. the
representative of 802.3 not passing along the vote and even consensus
of 802.3).

(I'm pointing at an infamous IEEE boondoggle to minimize offending IETF
participants and not because there are no IETF examples.)

Vernon Schryver    [email-masked]

---

From: Ofer Inbar <[email-masked]>
Date: Sun, 11 Feb 2001 19:09:25 -0500

> is trivially proven for the IETF by referring to the RFC index.

I don't disagree with you, but note that I was careful not to say
"produce a document", but "produce a standard".  Many working groups
produce documents that don't end up being widely applied, or useful,
or standards.  Sure.  But I don't think you'd argue that the HTML 3
working group of the mid-90s was a success, or that their lack of
results was a boon to interoperability.

Also, the question of whether or not failure to produce a document is
a good thing in particular cases, is beside the point.  It doesn't
change the fact that people *are* paid to prevent working groups from
developing protocols (whether they produce documents or not).  Saying
that this may not be necessarily bad is not the same as saying it
doesn't happen.

  --  Cos (Ofer Inbar)              --  [email-masked] [email-masked]
  --  Exodus Professional Services  --         http://www.exodus.net/
  "OSI is a beautiful dream, and TCP/IP is living it!"
   -- Einar Stefferud <[email-masked]>, IETF mailing list, 12 May 1992

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 12 Feb 2001 08:56:36 +0800

I like to chip in my 5cent worth.

I think it is sometimes worthwhile to rethink on the process to a
standards vs the intention of that process. We, at IETF, sometimes
forget the process is there for a purpose. Particularly, this process
foster the review among technical peers so as to produce a standard
which is scalable, robust and actually usable.

But more importantly, it to ensure people actually use the standard
defined.

In the past, the IETF could put an iron clap on those who dont use the
standard ("if you dont switch to DNS from your host.txt, don't complain
you can't resolve hosts"). In recently years, the IETF wins by pure
technical merits which makes sense to community. But it has become more
and more apparent that technical merits can bring us only this far.
There are other factors which determine whether someone would adopt a
IETF standard such as policies.

As such, perhaps it is important to rethink on the role for a IETF WG
chair, whose roles used to bring the WG thru the IETF process. It is
much more than that.

IMHO, a successful WG is one whereby it has been successful been adopted
and used by the industry.

-James Seng

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 11 Feb 2001 21:27:36 -0800

>is more often a success than a failure.  On the other side of the coin, a

Indeed. The ability to charter and re-charter a WG is a privilege and 
not a right. There are several types of WGs that might best go 
unchartered or not re-chartered:

A. The WG chartered to "combine the best features of protocols X and Y".
B. The WG chartered to produce a standard in an area in which there
   is no running code. 
C. The WG that is behind on its milestones by more than two years.
D. The WG that is chartered to document (for standards status) an
   existing protocol. 

I leave it to the reader to think of examples of WGs A, B, C and D. 
Such WGs have existed in the past and continue to exist in the
present. However, I question the wisdom of continuing to charter
such WGs, particularly now when there is so much real work to be
done and so little precious time in which to do it. 

WG A, is by definition being chartered to produce a cross-breed. As
in real life, few cross-breed protocols have the genetic material to 
survive in the wild. Such a WG is more likely to produce a protocol
with *all* of the features of X and Y (and then some) than to focus
on the *union* of functionality common to the problem attacked by
protocols X and Y. 

Now it can be argued that the vendors behind X and Y might just go
out and do their own thing, and therefore that an IETF effort is
of benefit. There are two problems with this argument. One is that
having some vendor implementation experience -- even of the proprietary
variety -- might be just the thing to refocus the effort 
on customer needs. The second problem is that the attention 
of the IESG is a finite and valuable resource. Every minute 
spent on the WG A, B, C and Ds of the world detracts 
from the time available to supervise WGs more likely to 
make a difference. 

As for WG B, a fundamental premise of standards activity is 
that "we only standardize things we know how to do." This
makes sense if only because it is hard to create a 
charter and milestones for a WG in an area where there
has never been running code. Such a WG would
be better chartered in the IRTF, which can develop
implementation experience to the point where the problem
can be better defined. 

WGs like C that have gone way off their schedules are problematic
for a number of reasons. Firstly, we know that WGs that take
more than five years to complete their first milestones
are generally less likely to result in widely deployed 
protocols than those that finish sooner. A WG that misses
its milestones by more than two years is a candidate to
become an "IETF lifer" and so deserves further scrutiny,
if only because the Internet changes so rapidly that the
world is often different after two years. Thus, the
WGs original assumptions may not longer be valid by the
time the work is finally completed. 

Once a WG slips its schedule by two years, it is time
to examine the reasons behind the slip and reassess the 
environment into which the protocol will be deployed. 

WG C can get badly off track for many reasons -- poor leadership
being one of the most common. However, another common reason
is that the problem definition itself is inadequate or that a 
fundamental assumption underlying the original approach 
is invalid. 

In such a case, the IESG should feel no obligation to
allow the WG to continue. The IESG does some of its best
work in shutting down WGs that have lost their way. If
the fault lies with the problem definition, not the work
itself, then one or more WGs can be subsequently chartered
with a sharper focus. If the problem lies with the leadership
of the WG, then perhaps new leadership will do the trick.

WG D is in effect chartered to give a proprietary protocol
the IETF's stamp of approval. However, the IETF is not a
rubber stamp, and if the proprietors wish to retain de
facto or de jure change control, then their protocol
should not be accepted on the standards track.  

with a better focus.

---

From: Kevin Farley <[email-masked]>
Date: Mon, 12 Feb 2001 06:29:17 -0800 (PST)

> and used by the industry.

Like NAT?

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

---

From: [email-masked]
Date: Mon, 12 Feb 2001 09:47:00 -0500

> > and used by the industry.

NAT has been adopted and used by the industry.  There's no consensus on
whether it was successful.

<as he prepares to duck> ;)

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech