Subject: TDMoIP Draft Support

From: "Radu Craioveanu" <[email-masked]>
Date: Fri, 19 Jul 2002 14:44:47 -0400

To whom it may concern,

Narad Networks is currently in partnership with Rad Data communications and
using the TDMoIP products from RAD.  Narad's customers are the cable MSOs.
Narad's technology transforms the coax infrastructure into "Virtual Fiber".
The coax infrastructure is turned into a Gigabit Ethernet network with
ATM-like QoS.  One of the most successful business propositions to our
customers is to enable them to leverage the existing TDM investments while
they migrate to a faster, more cost effective transport paradigm offered by
Narad hardware solutions.  Our 1 Gbps Ethernet network with CBR support
enables our partner RAD's TDMoIP technology to offer such TDM transport
services.

We fully support RAD in their standardization efforts
"draft-anavi-tdmoip-04.txt", as that will promote further our customers'
interests.

Sincerely yours,

Radu Craioveanu
Director of Product Management
Narad Networks
515 Groton Road, Westford, MA 01886
www.naradnetworks.com
[email-masked]
978-239-7537 Cell
978-589-1932 Direct
978-589-1821 Fax

---

From: Shahram Davari <[email-masked]>
Date: Thu, 25 Jul 2002 10:29:47 -0700

> Do you have any *technical* reasons why draft-anavi-tdmoip-04.txt
> is a Good Idea? (My liking it because it has less than ten authors
> wouldn't count, for example.)
> 

A quote from Thomas Nadeau (Cisco):

"The mantra at the IETF is "working code and rough consensus. Sounds like we base things on real implementations around here to me."

I suspect a well "running code" in real networks for ~3 years, could be a good justification for being a good idea.

-Shahram

---

From: Danny McPherson <[email-masked]>
Date: Thu, 25 Jul 2002 11:36:29 -0600

I think it was the marketing tone of Radu's message that 
triggered Lloyd's reply (I sent a private reply as well).  

As for "rough consensus and running code", I think this and 
a number of other working groups would be, well, less useful,
if we followed this strictly.  Though I do believe this
would be harmful to the larger Internet in the long run.

The trigger for my query regarding that particular draft was
regarding interest in multi-vendor support and interest in 
implementation, I think that's been demonstrated.

-danny

> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Shahram Davari <[email-masked]>
Date: Thu, 25 Jul 2002 11:34:04 -0700

Danny and Scott,

So let's clarify this once and forever to remove any doubt:

Is IETF's work based on "rough consensus and running code" or not?

-Shahram

> -----Original Message-----
> From: Danny McPherson [mailto:[email-masked]]
> Sent: Thursday, July 25, 2002 1:36 PM
> To: [email-masked]
> Subject: Re: [PWE3] TDMoIP Draft Support 
> 
> 
> 
> > "The mantra at the IETF is "working code and rough 
> consensus. Sounds like we base things on real implementations around 
> > here to me."
> > 
> > I suspect a well "running code" in real networks for ~3 
> years, could be a good justification for being a good idea.
> > 
> > 
> > -Shahram
> >

---

From: "Khalid Ahmad" <[email-masked]>
Date: Thu, 25 Jul 2002 16:06:00 -0400

Hi Shahram,

I know your question was not addressed to me, but I worry about this one
too.  

Many people have told me that IETF works on the principle of so-called
"rough consensus and running code", whatever that means, but I hope its not
a gating consideration any longer in defining standards for the industry.

In todays environment, I would be reluctant to build my business on someones
idea of what constitutes rough consensus and running code.  Anything can
run, if one throws enough software (or hardware) at it, but does it make
sense ?

I prefer well thought through standards that have wide industry support, as
I suspect you do to.  I would like IETF to work in that mode as well, as far
as possible.

Regards,
Khalid

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 2:34 PM
To: [email-masked]'; [email-masked]
Cc: 'Scott Bradner'
Subject: RE: [PWE3] TDMoIP Draft Support 

Danny and Scott,

-Shahram

---

From: "Ron Cohen" <[email-masked]>
Date: Fri, 26 Jul 2002 07:55:04 +0200

Shahram
 
> Is IETF's work based on "rough consensus and running code" or not?

I don't underestimate the fact that RAD's implementation has been
working for 3 years. 
I don't underestimate the fact the OEMs of the RAD implementation are
willing to say that this implementation is a good one. 
I don't underestimate the fact that AAL1/AAL2 ATM chips exists and can
be used to help in the NSP functions.

Does this imply "rough consensus"?
Does this imply that "running code" of a single vendor should be enough
to make it a standard one?

I suggest that we continue and discuss the applicability and pros and
cons of the AAL1/AAL2 solution as compared to other alternatives. 

Ron

> > The trigger for my query regarding that particular draft 
> was regarding 
> > interest in multi-vendor support and interest in implementation, I 
> > think that's been demonstrated.
> > 
> > -danny
> > 
> >

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Jul 2002 11:26:22 +0100

Rather than let this get bogged down in politics why
not perform the technical analysis I suggested to the 
list yesterday:

"Each of the TDM design teams should write a network resiliency 
statement indicating network delay, jitter, packet drop rate, 
transient rate and transient duration that they are resilent to,
and the behaviour when this is exceeded.
 
"They should also state for reference the above network
characteristics assumed by the native service designers."

ie we base the decision regarding running code on an objective
technical assessment of the term "running".

Stewart

---

From: Shahram Davari <[email-masked]>
Date: Fri, 26 Jul 2002 06:45:21 -0700

Ron,

You are absolutely right. What I was trying to show was only the "running code" part of the
equation, which was meant as a response to Lloyd, that asked why do some people think this 
draft is a good idea.

We definitely need the "consensus" as other important part of the equation.

-Shahram

> From: Ron Cohen [mailto:[email-masked]]
> Sent: Friday, July 26, 2002 1:55 AM
> To: Shahram Davari; [email-masked]; [email-masked]
> Cc: 'Scott Bradner'

---

From: [email-masked]
Date: Fri, 26 Jul 2002 09:34:53 -0600

Some comments in-line. 

> From:	Khalid Ahmad [SMTP:[email-masked]]
> Sent:	Thursday, July 25, 2002 2:06 PM
> To:	Shahram Davari; [email-masked]'; [email-masked]
> Cc:	'Scott  Bradner'
> "rough consensus and running code", whatever that means, but I hope its
> not a gating consideration any longer in defining standards for the
> industry.
> 
	[White, Craig]  
Not like this was addressed to me either :) But before you read too much
into a "one liner", a look at the thought process that condensed a rather
complicated idea into 5 words is probably in order. 

I would suggest a careful reading of RFC 2026
(http://www.ietf.org/rfc/rfc2026.txt). 

For example, you will find the following in section 1.1:
In general, an Internet Standard is a specification that is stable and
well-understood, is technically competent, has multiple, independent, and
interoperable implementations with substantial operational experience,
enjoys significant public support, and is recognizably useful in some or all
parts of the Internet.
This perhaps is a more precise definition of the concept of "rough consensus
and working code". The "rough consensus" must be technically competent, and
the "working code" must be multiple, independent and interoperable
implementations.

Section 4 which outlines the progression of a standards track document also
provides some very useful information about the requirements (gates if you
will) on how and when a standard is progressed.

Of particular note, there is a certain amount of iterations that has to
happen between a protocol moving from proposed standard to an Internet
Standard. A lot of stuff has to happen to take a design team or individual
draft document (note that one is just as good a starting point as the other)
to fruition as an Internet Standard. 

For example, I would say we are approaching the following stage on our way
to proposed standard from the drafts in PWE3. Lifted from section 4.1.1.
is generally stable, has resolved known design choices, is believed to be
well-understood, has received significant community review, and appears to
enjoy enough community interest to be considered valuable. However, further
experience might result in a change or even retraction of the specification
before it advances. 
We obviously are not at this stage yet and the last sentence is of
particular importance.
Then for the proposed standard to become a draft standard the following is
required. (sec. 4.1.2)
A specification from which at least two independent and interoperable
implementations from different code bases have been developed, and for which
sufficient successful operational experience has been obtained, may be
elevated to the "Draft Standard" level. For the purposes of this section,
"interoperable" means to be functionally equivalent or interchangeable
components of the system or process in which they are used.
Also there is verbiage about protocol options at this point....
The requirement for at least two independent and interoperable
implementations applies to all of the options and features of the
specification. In cases in which one or more options or features have not
been demonstrated in at least two interoperable implementations, the
specification may advance to the Draft Standard level only if those options
or features are removed.
While the above contains my interpretations of where we are with respect to
RFC 2026. RFC2026 appears to be very clear and concise (Thanks for the
edit(s) Scott!) and like all standards your interpretation my be different.

I would like for us to make progress in PWE3 and getting a draft accepted as
a working group document does not a standard make. Furthermore, if you think
you will be able to claim RFC compliance via an optional mode you managed to
strong-arm into a draft, you will be very disappointed in the outcome
without buyin from the other stake holders (vendors, service providers, "the
market"), you will most likely spend many years of fruitless work and waste
the time of countless people.
 
Cheers!
-craig

> In todays environment, I would be reluctant to build my business on
> someones idea of what constitutes rough consensus and running code.
> Anything can run, if one throws enough software (or hardware) at it, but
> does it make sense ?
> 
> I prefer well thought through standards that have wide industry support,
> as I suspect you do to.  I would like IETF to work in that mode as well,
> as far as possible.
> 
> Regards, 
> Khalid 
> 
> 
>

---

From: Scott Bradner <[email-masked]>
Date: Fri, 26 Jul 2002 11:42:43 -0400 (EDT)

note that "running code" comes *after* the selction of teh technology
and *before* advancement from proposed std to draft std

running code is clearly a good idea earlier in the game but it
should not be used to box the WG into a particular path
if there is not consensus that the path is the correct one technically
and IPR-wise

Scott

----
>From [email-masked]  Fri Jul 26 09:45:49 2002
From: Shahram Davari <[email-masked]>
To: "'Ron Cohen'" <[email-masked]>, [email-masked], [email-masked]
Cc: "'Scott  Bradner'" <[email-masked]>
Subject: RE: [PWE3] TDMoIP Draft Support 
Date: Fri, 26 Jul 2002 06:45:21 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"

Ron,

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Fri, 26 Jul 2002 08:56:35 -0700

Seems reasonable.

-Shahram

> From: Scott Bradner [mailto:[email-masked]]
> Sent: Friday, July 26, 2002 11:43 AM
> To: [email-masked]; [email-masked]; [email-masked]; Shahram Davari
> Cc: [email-masked]

---

From: Chris Liljenstolpe <[email-masked]>
Date: Mon, 29 Jul 2002 19:15:31 -0400

Khalid,

        You miss the point.  The process is that the IETF must have 
consensus (not total agreement) AND that the spec must be such that 
multiple implementers can implement the spec in an interoperable manner. 
If there is NOT consensus, OR there is NOT a viable spec, it doesn't make 
it on the standards track.

        What's wrong with that?

        Chris