Subject: comment on draft-fenner-zinin-rtg-standard-reqts-00

From: JP Vasseur <[email-masked]>
Date: Wed, 3 Aug 2005 08:11:22 +0200

Hi,

I'll provide more specific comments in a separate email but at a high  
level I found this ID quite useful and very welcome. Just a quick  
feed-back on one specific aspect discussed in the meeting yesterday:  
the number of required implementations for PS.

I would personally prefer to see one implementation required for PS.

Now, if two implementations are required then I found this a bit  
inconsistent with the absence of requirement for operational  
experience: in practice, if two implementations exist, it is very  
likely that the protocol will be deployed, thus operational  
experience would exist.

Thus,

My preferred option:

for PS:
Implementation =1
Operational experience=No

or

Implementation =2
Operational experience=existent (at least minimal)

Thoughts ?

JP.

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

---

From: Tony Li <[email-masked]>
Date: Wed, 03 Aug 2005 09:31:08 +0200

JP,

My concern with this approach is that it would allow any single
implementation (and company) to push to the PS level.  I'd very much
prefer that we see some kind of consensus between parties long before we
reach PS.

Tony

JP Vasseur wrote:
> likely that the protocol will be deployed, thus operational  experience
> would exist.
> 
> Thus,
> 
> My preferred option:
> 
> for PS:
> Implementation =1

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Aug 2005 07:58:50 -0400

> prefer that we see some kind of consensus between parties long before we

I agree with Tony here.  We should require two implementations and
require at least minimal operational experience.  This keeps good
ideas that never really catch on from becoming standards.  If a
protocol has only one implementation or no operational experience,
then it can become experimental to be moved to PS later or it can just
go to informational if there is little interest in input from the
standards process (for example proprietary protocols that are
documented as informational RFCs).

One implementation and no implementation experience equals
experimental.

Curtis

---

From: Scott W Brim <[email-masked]>
Date: Wed, 03 Aug 2005 14:03:21 +0200

On 08/03/2005 13:58 PM, Curtis Villamizar allegedly wrote:
> require at least minimal operational experience.  

Agreed.  That's what makes this the IETF.

> One implementation and no implementation experience equals

Yup.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 3 Aug 2005 15:08:14 +0200

Hi,

> require at least minimal operational experience.

this is why I proposed option 2:
- 2 implementations
- Operational experience=existent (at least minimal)

but found that requiring 2 implementations and no operational would  
be a bit non consistent.

>   This keeps good

agree but actually option 1 was what about one implementation and  
large operational experience?

JP.

>>> experience

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Aug 2005 09:38:19 -0400

> large operational experience?

That equals zero implementations that were written from the spec.

Having two implementations provides some assurance that the spec has
sufficient detail to make it possible to write an implementation from
the spec that will interoperate with the existing implementations.

One implementation equals experimental or informational until a second
comes along.  If it is really important to have something go to PS
fund a university or an independent contractor to write a second
implementation from the spec.

Curtis

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 09 Aug 2005 13:58:02 -0700

I think before we go any further with this thread it would be nice if 
one brings the precise definition of the "implementation" word. Further 
it may be nice to include it in the draft as well :).

The current draft between lines makes an implementation = vendor (or 
party) and if so the below suggestion to hire a university student may 
not always work :).

So what is an "implementation" ?

#1 Is this a guy sitting behind a keyboard and writing a feature or 
extension from scratch

or

#2 Is this a commercial or not commercial entity shipping or 
distributing a product or set of products with a feature or given 
extension ?

If this is the former there easily can be a cases when a single company 
has many independent implementations of the given feature. I know at 
least three such companies which could achieve the stated goal ! Would 
it count ?

As a comment to JP's #2 I don't see any inconsistency with requirement 
for at least two vendors participating in the implementation report for 
  a given feature and lack of yet another formal doc describing some 
operational experience.

Point to keep in mind that operators are not usually very willing to 
describe for their competition use what is running in their networks for 
many reasons. Such a requirement would for sure result in very nice slow 
down of any IETF WG progress with the process.

Cheers,
R.

---

From: Fred Baker <[email-masked]>
Date: Tue, 9 Aug 2005 15:14:10 -0700

To my knowledge, an "implementation" has always been a body of code  
(or corollary bit of hardware) that did what a specification said,  
and was implemented from the specification as opposed to by reference  
to or derivative from another implementation. For example, in TCP, I  
told that world-wide there are perhaps three commonly used  
implementations - all others derive from those three, with the  
exception of a VERY few proprietary implementations-from-scratch.  
Similarly OSPF; I know of five implementations (Proteon, Cisco IOS,  
3COM, University of Maryland, and one in Jon Moy's book); I would  
guess there are a few other truly-separate implementations around  
(does IOS-X have a separate one?), but I'll bet they are few.

The matter of commercial ownership is, IMHO, a red herring. The  
University of Maryland OSPF code was developed by a grad student  
named Rob Coltun. It has seen a lot of commercial deployment... RFC  
1246 (7.4) describes this test:

     The third round of OSPF protocol testing took place at 3com's Santa
     Clara facility, the week of February 4, 1991. Five implementations
     participated, from the vendors 3com, ACC, Proteon and Wellfleet  
and the
     publicly available University of Maryland implementation  
(running on a
     SUN workstation).

The ACC routers were mine. In that test, the Sun workstations, the  
Wellfleet implementation, and the ACC implementation were all UMd  
code running on something or another. There was also a fourth test,  
in which 23 vendors showed up. In that test, Proteon, Cisco, and 3COM  
had independent implementations - the rest were all based on the UMd  
code. When we talk about multiple independent implementations, for  
OSPF there were three commercial implementations and one university  
prototype, and that was sufficient for the purposes of standardization.

On Aug 9, 2005, at 1:58 PM, Robert Raszuk wrote:

> The current draft between lines makes an implementation = vendor  
> (or party) and if so the below suggestion to hire a university  
> student may not always work :).
>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 11 Aug 2005 11:48:47 -0400

In message <[email-masked]>
> So what is an "implementation" ?

We haven't had a need to formally define implementation.  We never
really defined deployment either.

This is not a definition but a clarification.

If a routing protocol or change is applicable to inter-domain routing
then an implementation is code that must be viable to deploy in
inter-domain routing in today's Internet.  If its university proof of
concept code running on Linux in someone's back room and is missing
key requirements (like interaction with an IGP for example), that
generally would not count.  If it were a complete implementation that
ran in something open but not on a commercial router capable of core
speed forwarding (as gated once was prior to NSF use and after it was
no longer open) then we have a gray area and in the past we called
that a reference implementation.

Similarly if a routing protocol or change/extension is applicable to
inter-domain routing then a deployment must be in inter-domain routing
in today's Internet.  We have in the past required that the deplyment
be in at least tier-1 or tier-2 if there is any question regarding the
change not scaling in larger deployments.

Its probably worth keeping these aspects of our existing
implementation and deployment requirements if we decide to formally
define these two terms.

btw - We are sounding less like engineers and more like a bunch of
lawyers and its only going to get worse if someone comes along
claiming to adhere to the letter or the requirement but trying to
short cut the intent.

Curtis