Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt

From: "Sanjoy Sen" <[email-masked]>
Date: Mon, 25 Jun 2001 19:19:18 -0500

Here're my comments/feedback on the Midcom requirements draft:

================

1.1.   Background 

Session *orientated* applications - Typo

>This is because there are implicit 
         relationships between individual packets that must be maintained 
         between hosts across the network 
	
For completion, we should probably add to this sentence the following: "and
this end-to-end relationship may be broken by the Middle-box."

Section 3: Definition of flow - incomplete, need to add "over a specific
transport protocol".

4.1.   Middlebox functions 

> The Middlebox must support the explicit forwarding of application 
         control session information received on one, or more, destination 
         address/port combinations to an appropriate MIDCOM Agent(e.g. an 
         application gateway) as described in section 7.

This alludes to the diversion function, which should not be mandatory as per
the current thoughts of the working group.

Typo in line 4 of 4th para - MICOM should be MIDCOM

4.4.   Distribution of MIDCOM elements 

>The Middlebox therefore needs to support multiple simultaneous MIDCOM 
         Agents ... 

Suggest that we add "and vice-versa".

5.     General Protocol Requirements

>The MIDCOM protocol needs to address three distinct aspects:- 
          
           - The association of MIDCOM Agents and Middleboxes 
           - The establishment of an Application Control flow in conjunction

             with the Middlebox and an appropriate MIDCOM Agent 
           - The establishment of an Application Content Flow through a 
             Middlebox according to rules determined by an associated MIDCOM

             Agent

The protocol need to address "establishment" as well as "termination" of
Application control and content flows. Suggest that we also add a fourth
bullet:
		"- Should allow messages to modify existing states during
the run-time phase of the 
		  connection according to the rules determined by an
associated MIDCOM Agent" 

Section 5.1. Typo in last but one line - "specify" instead of "specific"

Suggest that the following sentence be added at the end of the section: "The
protocol should allow the Midcom Agent manipulate individual connection
leg/direction (through the Middle-box)."

Section 5.2.1. Pin-hole Specification

>The "Packet modifier" must be able to change the 
         following protocol header fields 
              
             IPv4: IP addresses, TOS field  ...

Packet modifiers will have different functions depending on the specific
Middle-box. Hence, the "must" in the sentence above should be changed to
"may".

A minimal set pin-hole specification (which will be extensible) need to be
defined. The specification shown in Section 5.2.1 can be there for the
purpose of an example. These cannot be made mandatory at this stage. Suggest
that we add the phrase "For example, " to the sentence "The requests
communicated between a MIDCOM Agent and a Middlebox need to permit pin-holes
..."

>This directionality 
         shall be expressed as "in", "out" or "Loopback" (meaning both "in" 
         and "out" of the same side of the same Middlebox realm). 

This directionality can be specified by other means too. Suggest that we add
the sentence "The specification of the directionality should be kept
implementation dependent."

5.3.   Pin-hole operations 
          
>The MIDCOM protocol needs to support two basic operations; the 
         opening an closing of pin-holes across a Middlebox.

What about refreshing pin-hole states? Suggest that we change this sentence
to the following: "The MIDCOM protocol needs to support three basic
operations; the opening, closing and refreshing of pin-holes across a
Middlebox."

5.3.2. Close Pin-Hole

Suggest that we also add the case where the pin-hole will be closed when the
media path communication is broken. In this scenario, the Middle-box should
be able to report to the Midcom Agent about this status change.

5.4.   Pin-Hole reporting

"The Middle-box and the Midcom Agent should asynchronously be able to
exchange resource availability information related to pin-holes." Suggest
that we add a sentence like this in this section.

6.     Agent and Middlebox association

6.1.   Midcom Agent Registration

Suggest that a brief description of the profile be added. Midcom Agent
profile: The profile shall contain, at the very least, the identity of the
Agent and the type of services that it may request.
 
6.3.   Error handling

Suggest that we add - "The Agent and the Middlebox need to exchange periodic
keep-alive messages after the establishment of a communication session
between the two. This shall enable removal of any pinhole state which had
been established by an Agent which is no longer active. However, provision
should be there to allow for fail-over protection (if any) to take place
before the state is finally removed."

Section 7 talks about diversion function, which as per the current thoughts
of the WG, should at best be treated as optional. The text should be changed
to reflect this.

9.     Resource control requirements 

Suggest that we add, somewhat in similar vein to Section 5.4 above, - "The
Middle-box and the Midcom Agent should asynchronously be able to exchange
resource availability information. This will allow some flow admission
control decisions to be off-loaded from the Middlebox to the Agent.

Also, the Agent shall be able to independently control/manipulate the
resources associated with the flow in each direction (e.g., each call leg)."

10.1.  Status reporting 

Tracing exceptional situations & reporting to the Agent should be a
requirement. "The Middlebox shall be able to capture logs of exceptional
conditions (e.g., arrival of unauthorized packets) and report them to the
Agent."

10.9.     Protocol Performance

>The protocol needs to support time-constrained operation to enable 
         scalability of the complete solution ...

Suggest that we add the following phrase after "solution": "and to minimize
the impact on call set-up delay for certain types of multimedia
applications."

Regards,
Sanjoy