SDRP working group

Tony Li <tli@cisco.com> Wed, 18 November 1992 02:54 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04281; 17 Nov 92 21:54 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04277; 17 Nov 92 21:54 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa20703; 17 Nov 92 21:53 EST
Received: from pizza by PIZZA.BBN.COM id aa20796; 17 Nov 92 21:47 EST
Received: from BBN.COM by PIZZA.BBN.COM id aa20792; 17 Nov 92 21:46 EST
Received: from lager.cisco.com by BBN.COM id aa14372; 17 Nov 92 21:46 EST
Received: by lager.cisco.com; Tue, 17 Nov 92 18:45:54 -0800
Date: Tue, 17 Nov 1992 18:45:54 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tony Li <tli@cisco.com>
Message-Id: <9211180245.AA00735@lager.cisco.com>
To: jnc@ginger.lcs.mit.edu
Cc: B.Kumar@cs.ucl.ac.uk, tli@cisco.com, iwg@ans.net, idpr-wg@bbn.com, idrp-ip@merit.edu, jnc@ginger.lcs.mit.edu, unified@caldera.usc.edu
In-Reply-To: Noel Chiappa's message of Tue, 17 Nov 92 16:45:30 -0500 <9211172145.AA07796@ginger.lcs.mit.edu>
Subject: SDRP working group

[This is just the same response that I gave Noel in the hallway...]

       If you look a bit farther (see the SDRP charter), you will find that
       we do have further information gathering facilities planned for the
       protocol.  Route computation is, at this point, a very open research
       problem.  Note that these enhancements are in some sense detached from
       the current spec, as the functionality in the current spec dos not
       rely on these enhancements.

   Looking under the street lights again, I see. This is a bit of a
   cop-out; you've left the *hard* part to the end again. 

This is true.  This is because the part that we HAVE done is useful in
and of itself.  It solves some of the problems that currently exist in
the Internet.  No, it does NOT solve all problems, just as static
routing did not solve all routing problems.

       Is this anything other than a semantic quibble over the definition of
       a "routing protocol"?

   Aw, come on, Tony, I didn't expect this sort of stuff from you.
   This protocol has next to nothing to do with the functionality that
   we have come to expect from something calling itself a "Routing
   Protocol".  You're right, it is just semantics, but there are a lot
   of people serving jail time for things that are just "semantics"
   (e.g. for fraud). Semantics *are* important; it's hard to make the
   case that this title was not deliberately misleading.

You misunderstand me Noel.  I was not denigrating the comment.  I was
trying to distinguish naming (editorial) from content (technical).  If
the objection is that the title is unacceptable because the current
draft does not contain topology information and route computation,
then I have no objections to changing the title to something like
"Source Demand Routing Protocol (Version 1): Part 1: Forwarding and
Control Messages".  

If the objection is that the unconventional map distribution mechanism
and route feasibility computation that we intend to use for SDRP
(which you haven't seen yet) does not constitute a routing protocol,
then I question your definition of a "routing protocol".

Tony