Subject: [karp] Design Guide: Phase 1 work

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Nov 2010 02:44:44 -0500

Hi.
Section 4.2 of the design guide  implies that the design teams should:

* Describe the current state of the routing protocol
* Describe optimal state
* Describe gap analysis

That's probably how you have to do the mental exercise.  However, I
think that's probably not an effective way of writing it up.

Dacheng and I received some indirect criticism of our OSPF analysis
draft from the chairs.  We're meeting with them to get the specifics,
however, in reviewing the draft, I realize that it's not organized very
clearly.

I think that's an effect of two considerations, one of them following
from the design guide advice.

When trying to describe something, you end up wanting to focus on the
important parts.

It's a lot easier to describe that if you can explain the important
parts earlier.
So, I'd actually recommend that when writing up issues with a protocol:

* Break down the important issues. Probably this looks like a lot of
  high-level requirements. For example things like "OSPF needs to
  provide intra-session and inter-session replay protection," and "OSPF
  needs to provide an integrity mechanism that can work on the hardware
  that is used for OSPF."

* Motivate the requirements--what breaks if you don't meet them. 

* Describe where you are with regard to these requirements particularly
  with focus on what is wrong.  In particular I found it very difficult
  to separate the discussion of the current state from an evaluation of
  whether the current state is good. I think trying to perform this
  separation adds confusion.

* Describe what needs to be done.  Here I'm not sure it is going to be
  helpful to separate the specific proposal from the general problem.
  By this point   I think that people should already understand the
  problem

In addition, keep in mind you have two audiences:

*  Helping security folks understand the security properties of the
   routing protocol so they can understand why  the problems are real
   and why the solutions will work

* helping routing folks understand the problems and solutions.

I don't know that text in the design guide needs to change so long as
we're agreed that the design guide is describing what work needs doing,
not how it must be written up.