Subject: RE: [NSIS] What is the goal of the analysis draft?

From: [email-masked]
Date: Wed, 4 Dec 2002 06:28:10 +0200

Hi Mike,

> So, I'm not entirely sure whether an endless
> string of analysis papers is really what's needed
> so much as:
> 
> 1) Identifying Stovepiped Problems
> 2) Generalizing Them
> 3) Deriving Requirements
> 
> The question is what is the most expeditious route
> to get to (3). The SIP experience says that it's
> not easy when there are large culture clashes. I'm
> all ears.

I'd substitute 3) with.

 3) Bring them as input into the protocol work.

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 4 Dec 2002 07:31:43 -0800 (PST)

>  3) Bring them as input into the protocol work.

   I guess I disagree. To take a small example, one the
   problems I found with MIP/RSVP is the route damping
   problem. That is, an interior node seeing a new PATH
   for an existing reservation is going to want to back
   off to dampen flapping. This is great for the normal
   cause (interfaces bouncing), and lousy for MIP where
   the topology change is intentional. 

   Thus, I think it's fairly easy to derive a requirement
   out of that:

   o The protocol must allow for explicit and intentional
     topology changes which are not subject to route
     flap damping procedures.

   I'm not sure I'd want to leave it up to the protocol
   desiners to *realize* that's a requirement if it's
   just in the middle of some analysis document. However
   we structure the process, we need to place
   derive the MUST's and SHOULD's of what the NSIS
   protocol is in a readily referenced document,
   and I'd sort of think that's the requirements doc.

       Mike

---

From: Melinda Shore <[email-masked]>
Date: Wed, 04 Dec 2002 10:41:48 -0500

>    just in the middle of some analysis document. 

I absolutely agree with this.  I think that right now the
requirements document suffers a bit from the inclusion of
things that aren't really requirements (much of the
scalability section, for example), while it's one function
of a requirements document to bring out non-obvious
requirements like this one.  

Also, while I agree with the need to move as quickly as
possible, I don't think it's a good idea to try to move
*more* quickly than it's possible in order to head off
efforts by other standards bodies.  We need to produce the
best quality protocol we can within a reasonable time frame,
and I'd rather see us achieve that by constraining the
problem than by omitting important pieces of the process.

Melinda