Subject: Re: New draft of controlled-load service spec

From: [email-masked]
Date: Thu, 14 Dec 1995 09:24:15 -0800

*> 
  *>     A protocol spec must define a representation.  The current thinking is
  *> a service spec should not.  I'm happy to revisit this idea (it is clearly
  *> beginning to cause people some grief).   However, keep in mind that since
  *> RSVP is not the only user of the service, the data structures won't
  *> necessarily be optimized for RSVP.
  *> 
  *> Craig
  *> 

Craig,

Whether or not RSVP is the only user of the service, optimizing for
the RSVP case is exactly the right thing, in my (biased) opinion.
Again, I ask others in the WG to either agree or disagree with me.

Bob Braden

---

From: Craig Partridge <[email-masked]>
Date: Thu, 14 Dec 95 09:28:57 -0800

Bob:

    It isn't clear to me why RSVP should have any precendence over SNMP
or hand configuration tools as a mechanism to setup flows.  There will
be situations in which each one is appropriate.

Craig

---

From: Karl Auerbach <[email-masked]>
Date: Thu, 14 Dec 1995 11:49:59 -0800 (PST)

> Again, I ask others in the WG to either agree or disagree with me.

This discussion has me very, very bothered.

I write code.

I can't handle "generic"  descriptions.  I need to know the *exact*,
bit-by-bit layout of packets and their contents.

I certainly see no value in defering a precise, concrete representation 
of the information structure.

Is the int-serve message: "Here is the data one needs to exchange.
How you encode it in your own protocol is your own business."  ??

If that degree of freedom is intended than the RSVP crew and the SNMP 
crew can each independently choose their own representations. 

(And if so, then I suggest that data layouts be removed from the flow 
spec documents.)

I've been operating on the belief that we would see exact binary 
flow spec representations.

Changing (or clarifying) the policy so that int-serve says only what data 
is to be exchanged and letting RSVP or SNMP set the representation is OK 
by me.

		--karl--