Subject: [midcom] Confusion re. text in requirements-01

From: "Fleischman, Eric W" <[email-masked]>
Date: Tue, 26 Jun 2001 16:49:38 -0700

My first point is a question, the rest are text in requirements-01
that I wasn't able to grok.

In Section 5.3.2
Where the communication relationship between a Middlebox and a MIDCOM 
Agent are broken, all existing pin-holes must be closed. 
          
	Question: Are you requiring "keep alive" overheads?

In Section 6
A given Middlebox may support multiple concurrent trust relationships 
with a number of MIDCOM Agents. Resources, such as a Pinhole-
Descriptor, may be shared across MIDCOM Agents and a Middlebox. As 
Pinhole-Descriptors may be shared across Middlebox functions, a 
Pinhole-Descriptor may be created by one function, and terminated by 
a different one. 
          
	Are these two separate paragraphs (thoughts) or a single one?
      That is, what is a "middlebox function" in this context? Is 
	this text saying that different Midcom agents can terminate 
	each others sessions? If so, what controls are there if they
	are located in different security domains?

In Section 7.1
A MIDCOM Agent shall be able to request a pin-hole from a Middlebox 
for the purposes of establishing a presence on the external network. 
   
	I don't understand what the authors are saying in this paragraph.

In Section 10.8
If a peer does not understand an option it must be clear whether the 
action required is to proceed without the unknown attribute being 
taken into account or the request is to be rejected. Where attributes    

	What is a "peer"?    

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 27 Jun 2001 10:59:43 -0400

> 	Question: Are you requiring "keep alive" overheads?

The question is whether "we" are requiring them.

A middlebox needs to be able to kill off pinholes for whatever reason.
That means keeping state information, in order to remember to do so.
That state could be an absolute timer, and that's a reasonable option
but too rigid to have as the only one.  The alternatives are observed
traffic and/or keepalives.  If an agent chooses to use an absolute
timer, that's fine.  If it chooses to use keepalives, who should be
responsible for the keepalives?  The middlebox has to have state anyway,
in order to kill off the pinhole eventually.  The agent *may* need
state, but not all agents do.  I'm leaning toward having the middlebox
send a query toward the agent -- "do you still want this?", but I still
haven't done a decent analysis.

...Scott