Subject: [midcom] Comments on Framework 03 draft

From: [email-masked]
Date: Mon, 23 Jul 2001 02:21:52 +0100

Hi,

I have a number of comments on the 03 draft.

1. The In-path and out-of-path issue doesn't seem to have closed and there
is plenty of reference to it in the document. I have been thinking about the
view the protocol gets and it seems to be easier to position the protocol as
flowing between a middlebox and an Agent only - as per the text in some
places. The in-path and out-of -path issue then only becomes part of the
debate if the actual MIDCOM Agent is interpreted to be the whole ALG
function - which the document does in some places. If on the other hand, the
MIDCOM Agent is considered to be only that part of an ALG that talks to the
Middlebox from a control point of view, then the whole in-path and out
-of-path debate disappears. i.e.

        +--------------+
+--------------------+
        |    ALG     |                                   |       ALG
|
        +--------------+                                  |    +---------+
|
        |   MCA     |                                   |    |  MCA  |     |
        |               |                                   |    |
|     |
       + -------------+
+---+----------+----+ 
              ^                                                       ^
              |                                                        |
              v                                                       v
      +------------------+
+------------------+
      |   MIddlebox  |                                |  Middlebox   |
     +-------------------+
+------------------+
                   
Where MCA is the MIDCOM Agent. In the second case, the ALG would use the
MIDCOM Agent to route the session control streams (e.g. SIP messages) to the
ALG on another logical interface to the ALG as opposed to coming through the
Agent. If this is the case then whether the function the agent is part of
(i.e. the bigger ALG function) sits in the signalling path or not becomes
irelevant. So from this point of view I think it may be better to position
the MIDCOM Agent as purely being that part of a bigger function which
communicate with the Middlebox for command and control purposes. If this
approach is agreeable, then the discussion concerning in-path and
out-of-path can come out of the document.

Section 4 seems to have lots of embedded requirements concerning the
protocol. Is this the right place to put this stuff? I would suggest
possibly not.

Section 5 seems to have a lot of common text with section 2.8. Could these
be merged?

Section 6.1 seems to have a lot of embedded requirements 

Section 6.2 also seems to have a lot of embedded requirements

Section 8.2 seems to repeat section 4 and section 6.2.

nits
===
Page 1 and elsewhere. NetMeeting V3.x isn't always a peer-peer application
so it is a bit misleading to cite it. It can be - but not always.

I think the term "Message Sequence" might read a bit better than "Timeline
Flow" in section 7

Section 8.6 makes reference to Q.931 which technically isn't correct and
should probably read H.225.0 call signalling.

Hope this helps.

regards

Richard

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 26 Jul 2001 07:39:53 -0700 (PDT)

--- [email-masked] wrote:
> is plenty of reference to it in the document. 

I dont believe so. The In-path vs OOP issue is closed.
The document does not refer OOP agents other than simply stating 
that the discussion is out of scope.

>                                               I have been thinking about the

Richard - I wouldnt want to change the definition and function of an
agent to be the least common factor (i.e., between In-Path and OOP).
Limiting the definition to control and ignoring application data traffic
would be incomplete. Besides, the text, illustrations and WG discussion
thus far has been built around the current definition. 
I would rather not change that.

Your figures are garbled. 
                   
> out-of-path can come out of the document.

It is not my intention to work around the definition to fit the OOP 
agents. We had a spirited discussion and concluded that OOP agents is 
out of scope. I will go with that.

> protocol. Is this the right place to put this stuff? I would suggest

Richard - The framework cannot be described in a vacuum. The section 
simply talks about the phases in a MIDCOM connection setup. While some
overlap is inevitable, it is important to note that (a) the reader is not
required to have two documents (i.e., framework and requriements document)
in order to understand this document, (b) the requirements and framework
document should be in sync.

As far as I can tell, the focus of the text throughout has been the
framework in which the MIDCOM protocol will operate.

> Section 5 seems to have a lot of common text with section 2.8. Could these
2.8 is term definition for MIDCOM agent. 
5.0 is description and discussion on MIDCOM agents.
Some overlap is inevitable. I wouldnt want to merge the two.

> Section 6.2 also seems to have a lot of embedded requirements

Please see my comments earlier.
 
> Section 8.2 seems to repeat section 4 and section 6.2.
You are right. I will get rid of the text in section 8.2. 

> so it is a bit misleading to cite it. It can be - but not always.
I dont know about specific versions. I dont find this misleading.

> I think the term "Message Sequence" might read a bit better than "Timeline
It is just a word - same meaning. Works for me and many others.
I would leave it as is.

> should probably read H.225.0 call signalling.

Q.931 is the packet format exchanged over H.323 TCP connection. 
The Intel document that describes H.323 also refers the Q.931
and H.323 connections interchangeably. So, I suggest,
we leave this as is.

> Hope this helps.
Thanks.
 
> Richard

regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/