Subject: Re: [midcom] framework comments

From: "Philip Mart" <[email-masked]>
Date: Wed, 1 Aug 2001 17:38:05 +0100

Suresh,

Some nits I'm afraid:

Page 3 paragraph 1. Please change the words "Section 4 describes the nature of
MIDCOM protocol." to " Section 4 decsribes the nature of the task to performed
by a MIDCOM protocol."

We cannot describe the protocol or its nature because it has not been specified.
However describing the task it is expected to perform is , of course,
appropriate.

In the same paragraph, in the text referring to Section 7, change "in which the
MIDCOM agent is co-resident on a SIP proxy server" to "for the case where the
MIDCOM agent is co-resident on a SIP proxy server".

This removes any assumption, which could otherwise have been inferred,  that the
framework mandates the location of the agent on the same computing platform as a
SIP proxy.

I note that this has the same effect as a change requested by Richard Swale
which has received no response.

Section 2.1 First sentence. This is an extension of the definition of middlebox
but it implies that the middlebox and it's operations require application
intelligence. This is contrary to the purpose as described in the introduction.
"Middlebox functions behave in ways which vary according to the application
involved." may be text which conveys the same meaning as you originally
intended, is it? I recollect seeing  a similar request on this point in an
earlier post.

In the last line on page  3 change "of a middlebox function" to "of middlebox
functionality".  It would be helpful at this point to explain to the reader why
the examples you list are indeed middlebox functions, that is define the
charisteristics that single them out as middlebox functions by reference to
other documents or otherwise. The reason is that in the future applications will
arise which were not included in your list and the user can then determine with
confidence whether MIDCOM applies on a case by case basis.

Phil

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

---

From: "Philip Mart" <[email-masked]>
Date: Wed, 1 Aug 2001 17:45:10 +0100

Suresh,

Looking again at 2.2 on page 4 what is the point of all but the first sentence
in this subsection. Are we to deduce from its omission that a Load Balancing
middlebox is NOT a middlebox implementing Load balancing services. I suspect
that we are meant to assume that the principle of the two example is extended to
all middleboxes. The draft doesn't say so though!  I guess the best answer is to
delete all but the first sentence. Please prepend "A " to the first sentence.

2.3  I agree with Eliot that a definition from elsewhere is needed. In general
if we use our own words please write as little as possible to minimise the
detail which others disagree with! I fail to see how we can drop the "packet
filtering" words though. It is the immediate link by the reader between what
MIDCOM controlled middleboxes do and an applications level firewall that we
should avoid. The current wording fails to do this becasue the general
description of a MIDCOM controlled function was not spelt out earlier. Having
suggested that we drop all but the first(amended) sentence in 2.2 why not ditch
2.3 and 2.4 as redundant?

The NAT references could be reintroduced around Fig 1 if they are really
necessary to explain the framework.

2.5 last sentence change "can intercept" to "may be used in a configuration
where it intercepts", change "intercept only" to "only intercept". The last
sentence is not helpful please delete it.

2.6  I have much difficulty with the first paragraph because it implies that an
ALG looks at the traffic but Midcom agents are later defined as being ALG's
without the traffic!  Why not drop the second sentence in the first paragraph?

The third paragraph starts out by descibing that an ALG is not a proxy. This is
not necessary here. Delete the first sentence and then delete "the" from the
second sentence.

In the second paragraph the ALG is defined in terms of its location! If it were
not for the location why would the ALG be any different from the MIDCOM Agent in
the description of its functions.  Since I am not convinced that we can remove
ALG from the document because of its use in later tutorial text I suspect that
it may be wise to accept the suggestions that Richard Swale made on July 23 and
clarify the difference in a robust way.

I notice that ALG does not appear in the document in a sustantive way until page
15 and then 32 where it could be eliminated altogether with limited editing.
This sub-section needs to be re-written to clarify the difference between ALG
and MIDCOM agent.

2.8  At this point ALGs had all the application intelligence and MIDCOM agents
are external to the the middlebox. In the second paragraph we only deal with
in-path agents. BUT MIDCOM agents are external to the middlebox so they MUST be
OUT OF PATH! The notion that in-path means located on devices that are naturally
in the message path is rather hard to take. I have in mind an agent commanding a
middlebox which is principally a packet forwarder of some description which does
not pass traffic packets through the stack that it uses for receiving commands
from the MIDCOM agent. This sub-section declares that such configurations are
out of scope. In essence this is an implied requirement that the middlebox be
implemented on the same IP stack as a midcom agent. Such a requirement has not
been agreed as far I  remember , and if it has it shouldn't have been!

What I believe needs to be said is that "In-path means that a middlebox,  under
the control of a competent MIDCOM Agent,  is present in the message path
normally used by the application".

Didn't Richard urge you to drop all the in-path, out-of path stuff by defining
ALG differently?

2.9

I suspect that you did not mean the requirement implied by the first sentence
that the Policy server need not be taken as authoritative by a middlebox. What
did you mean to say?

I note that the second sentence is also in the requirements document in section
6.7.1. As regards the framework the existance of a different protocol, that is a
matter of protocol requirement and should not be stated here. I suggest you
delete the second paragraph.

The third paragraph starts out by saying that a policy interface which is
specifica to an application is out of scope for this document. Then in the third
sentence it describes a policy interface using SIP... but that is out of scope
for this document so why put it in? What also comes out of this is that the
policy about which flows to allow is the concern of a policy server but is then
disallowed only because it is found using an application specific protocol.

I suggest that you replace the whole of sub-section 2.9 with the word in
sub-section 4.3 of the current requirements draft, sorry about the overlap.

Phil

As mignt be expected this stems from the definitional confusion about ALG  in
2.6 and should be cleared up.