Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!PESCADERO.STANFORD.EDU!cheriton
From: cheriton@PESCADERO.STANFORD.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Gateway monitoring protocols
Message-ID: <8701211842.AA28609@ucbvax.Berkeley.EDU>
Date: Wed, 21-Jan-87 13:20:28 EST
Article-I.D.: ucbvax.8701211842.AA28609
Posted: Wed Jan 21 13:20:28 1987
Date-Received: Wed, 21-Jan-87 21:35:57 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 23
Approved: tcp-ip@sri-nic.arpa

Responding in part to Dennis's question,  it seems appropriate to me to view
security as a transport-level functionality (unless the security demands are
extreme and application-specific).  Thus, I would like to broaden his question
slightly to:
What is the currently thinking by those involved on the provision of transport
functionality for a monitoring protocol.  This includes: transport-level 
addressing, error control and sequencing, flow control and security.

My opinion: gateways are a service or server in the distributed systems sense.
We should be able to contact this service using a standard RPC-like protocol
suite, at least for monitoring and control.  Only gateway-specific
"procedures" need to be specialized, not the transport and presentation levels.

Getting there: Bob Braden's end-to-end task force is looking at various
candidates for a "transaction protocol" (see RFC 955). There has also been
some discussion of presentation-level protocols.  (I have a candidate
protocol, VMTP, responding to RFC 955 which I hope to RFC in the near future.)

It would be helpful for the monitoring protocol people to think in terms of
this protocol structure or else indicate why this approach is unworkable.
Otherwise, we may have an explosion of higher-level and management protocols,
all solving the transport and presentation levels issues differently.
David C.