Subject: RE: [Isis-wg] To standardize or not?

From: Jeff Parker <[email-masked]>
Date: Tue, 3 Feb 2004 10:18:47 -0500

> I believe providers trust implementations and proven
> interoperability more than theoretical standard
> documents.
> 
> This interoperability and functionality can be
> described in any document (standard or not) as long
> as it is agreed by the community of companies
> supposed to implement them.
 
Just one data-point on this.  We have providers
running conformance tests from vendors that test
out-of-date aspects.  There are various 'failures'
that we need to explain or implement around to get
past these gatekeepers.  I have tried going directly
to the vendor of the conformance suite, but they 
cite the appropriate 'standard'.  

I don't have much luck citing the interoperability
document to either party at present: it may have 
more mojo if it becomes an approved standard.  
It is difficult for a provider to figure out the
status of any particular document, as there are so
many, and they don't always agree.  I think that
status as a standard provides a bit more weight.  

Of course, others may have more luck with the 
document in it's current state than I do, 
as it could provide evidence of a second 
person with the same point of view.  

- jeff parker

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 04 Feb 2004 00:01:56 -0800

If I am totally honest about this subject, I have to admit I have a good 
deal of ambivalence.

On the one hand, I believe in the benefits of standardization. It forces us 
to get the details right, requires interoperability testing, and thereby 
can improve the quality of the RFCs we turn out. The fact that other 
organizations, notably the ITU, are currently forced to paraphrase IETF 
work in order to use it is highly undesirable and even somewhat 
embarrassing. I have also long felt that the amount of arcane knowledge 
required to produce an interoperable IS-IS implementation was larger than 
it needed to be - in part because as features evolve we don't always bother 
to formalize all the interoperability issues (though thanks to Mr. Parker 
and the two Interoperability drafts some of the obscurity has disappeared).

On the other hand, deployment of IS-IS for IP must be considered a success 
and I have heard no groundswell of complaints about the lack of 
standardization from customers. Perhaps it is because the community of 
implementors shares enough "napkins and libations" to keep interoperability 
issues at bay. Perhaps most users don't place a high value on standards 
tracking RFCs. Perhaps users are more interested in getting new features 
more quickly. Perhaps...

In any case, I have yet to see anyone volunteering to be the first among us 
to shepherd an RFC through the standards track (and yes - that group of 
non-volunteers includes me). And why should anyone volunteer? Answer:

Because

A)They place a high value on the standards process and
B)There is a strong business incentive to do it.

At the moment, I have a moderate amount of "A" but don't see much of "B". 
Makes it difficult to be more than mildly supportive. I am willing to help 
get the train moving, but I'm not eager to fight an uphill battle.

    Les

---

From: mike shand <[email-masked]>
Date: Wed, 04 Feb 2004 08:39:22 +0000

Like most opinion surveys, the answer you get depends on exactly what 
question you ask.

If the question had been "would you object to putting IS-IS on the 
standards track", I think the answer would probably be NO. There are 
clearly benefits in doing so, not least in sorting out the ITU situation.

However, if the question is "Would you support it?", then it becomes rather 
more difficult, since that implies some commitment (and that inevitably 
means expenditure of company resources) to performing the possibly 
extensive hoop jumping required to bring this to fruition.

It is easy to view the standardization as "A good thing"TM. It is somewhat 
harder to provide the business case to do it.

Or to put it another way. The end goal is clearly a nice place to be, what 
is not clear is whether the cost of the journey is worth the reward. Maybe 
it is; maybe it isn't.

What makes this a more difficult call than the normal standardization issue 
is that we are currently perhaps 80% of the way there (choose your own 
figure), but that last 20% may cost us a lot of resource.

If it were simply a question of putting a big "standard" rubber stamp on 
what we already have, then I think it would be a no brainer.

	Mike

---

From: Jeff Parker <[email-masked]>
Date: Wed, 4 Feb 2004 10:42:57 -0500

> we are currently perhaps 80% of the way there (choose 
> your own figure), but that last 20% may cost us a lot 
> of resource.
> 
> 	Mike

Mike -
	I will confess my total ignorance on this score.
I've always assumed that the last 20% takes 80% of the work.  
We have two implementations, which is often one sticking point.
But other work required?  

	There hasn't been a lot of time or money for me to attend
the meetings, but I'm happy to try to take one or more of the
interoperability documents as a test case if it is work I can
do from home.

- jeff parker