Subject: Re: Meta: goals for IETF Routing area

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Sat, 24 May 2003 16:26:59 -0400

What you wrote certainly seems correct.
Recently I've stumbled across a bunch
of things in which you can't count on implementation behavior.

One example is handling of router alert option, and in general
what can be trapped in the fast path. Some implementations,
apparently, will only trap things with router alert (so you
can't trap based on a new protocol type, or a UDP port).
Other implementations throw away packets with router alert.
Some implementations think router alert takes a parameter.
Others don't.  This sort of thing...

And then there's NAT. NAT wouldn't be nearly as bad to
design around if it were written down what NATs do, and
all NATs adhered to it.

So it's not just a matter of getting the designs sound and
the documentation comprehensible and complete. Maybe
we also need some sort of conformance hurdle, so that
there won't be widely deployed hacks that sort of work,
that interact badly with other deployed hacks that sort
of work.

Radia

"Alex Zinin" <[email-masked]> wrote:
>Folks-
>
> I started writing the message to start the discussion on
> under-specification vs over-specification and quickly realized that
> my thoughts are based on some fundamental assumptions about the IETF
> and the Routing area in particular. It seems that a discussion on
> this would be useful to at least realize where we all stand so we can
> understand where people come from.
>
> Here are some of the most basic statements I have in mind, by no
> means complete, but roughly what I think:
>
> S1: The goal of the IETF process is to produce technical specifications
>     that can be used to develop multiple independent implementations
>     that can interoperate with each other.
>
> S2: One of the direct responsibilities of the WGs within the Routing
>     area is to ensure continuos operational status of the Internet
>     routing system by maintaining scalability and stability
>     characteristics of the existing routing protocols, as well as
>     developing new protocols, extensions, and bug fixes in a timely
>     manner.
>
> Corollaries from the above:
>
> C1: Specifications produced within the Routing area need to specify
>     enough details to ensure that an informed reader unfamiliar with
>     the specific subject of the document can write an implementation
>     that a) can interoperate with others and b) does not affect
>     the aspects described in S2 above.
>
> C2: We (the routing community, including vendors, and users) need to
>     be able to conduct adequate review of proposals affecting the
>     Internet routing protocols so that we can filter out bad ideas,
>     fix bugs and improve the mechanisms by leveraging the collective
>     wisdom.
>
> Let's keep this warm and friendly, but open ;)
>
> Regards.
>     
>-- 
>Alex
>http://www.psg.com/~zinin/
>

---

From: Alex Zinin <[email-masked]>
Date: Tue, 27 May 2003 12:49:17 -0700

Radia,

...
> that interact badly with other deployed hacks that sort

My impression is that the IETF has historically tried to avoid getting
into the "interoperability/compliance testing" space. The only way
it is touched upon in the process is by requiring the implementation
and interop report when progressing specs along the STD track to
ensure high quality.

Cheers.
Alex