Subject: [midcom] comments and nits on framework-03

From: [email-masked]
Date: Mon, 23 Jul 2001 22:45:50 +0100

suresh, 

please find below my comments and nits list concerning the 03 framework
draft. I think the major issues are the inclusion and handling of the
scenarios in the document and also the relationship between the scope of the
MIDCOM Agent and the ALG which may help us punt the in-path out-of-path
issue once and for all.

regards

Richard

========

page 1 - NetMeeting v3.x doesn't necessarily fall under the class of
peer-peer applications as it can work with an H.323 gatekeeper. Perhaps this
reference should be moved elsewhere in the text or dropped.

page 2 - last sentence prior to section 1: ...complex applications <insert>
to operate correctly </insert>.....

page 2 - section 1 first paragraph: provides routing <delete> transparency
across </delete> <insert> indirection between </insert>

page 2 - section 1 first paragraph: (ALGs) <delete> are </delete> <insert>
may be </insert>

page 2 - section 1 first paragraph: ...payload <delete> so </delete>
<insert> in order that </insert> the...

page 2 - section 1 first paragraph last sentence: deployment of new <delete>
services </delete> <insert> applications </insert>

page 2 - section 1 second paragraph last sentence: ... degrade <delete> in
</delete> performance.

page 2 - section 1 third paragraph: can be <insert> safely </insert> removed
from....

page 3 - section 1 last paragraph: The remaining sections cover the.....
suggested replacement text "The remaining sections cover the components of
the framework, illustrations of the MIDCOM approach using example flows and
a consideration of operational issues."

page 3 - section 1 last paragraph: ... SIP flows using <insert> the
</insert> MIDCOM framework in which <delete> the </delete> a MIDCOM Agent is
co-resident <delete> on a </delete> <insert> with a </insert> SIP proxy
server.

page 3 - section 2.1: .....network <delete> intermediary </delete> <insert>
element </insert> that requires...... 

page 3 - section 2.1: Policy based packet... suggested replacement text
"Examples of middlebox functionality include policy based packet filtering
(a.k.a. firewalling), Network Address Translation (NAT), intrustion
detection, load balancing, policy based tunnelling and IPsec security."

page 4 - section 2.2: <insert> A </insert> middlebox is a network <delete>
intermediary </delete> device that implements one or more <delete> of the
</delete> middlebox services. <insert> For example,  </insert> a NAT
middlebox <delete> is a middlebox implementing NAT service. </delete>
<insert> implements NAT services and a firewall is a middlebox which
implements policy based packet filtering services.</insert> <delete> A
firewall middlebox is a middlebox implementing firewall service.</delete> 

page 4 - section 2.3: rephrase to read "A firewall is a policy based packet
filtering middlebox function, typically used for resticting access to or
from specific devices and applications. The policies used to control a
firewall are often termed Access Control Lists (ACLs).

page 5 - section 2.6. I would like to suggest we clarify the difference
between an ALG and a MIDCOM Agent. If we declare a MIDCOM Agent to be only
that functionality that makes requirests of a Middlebox to gain acess to its
resources and an ALG an entity which embodies application specific
functionality that enables a given application to function correctly in the
presence of a given middlebix device. Then the MIDCOM Agent _may_ be a
constituent element of an ALG (and will be if the ALG is using the MIDCOM
approach). This more importantly then means that the issue of in-path and
out-of-path instantly becomes irrelevant as the application messages don't
go to the MIDCOM Agent (which is clearly the case since the MIDCOM protocol
is only asking for pin-holes to be openned and closed and not directly
involved in the processing of the application messages).

page 5 and page 6 - section 2.8: all of the discussion concerning in-path
and out-of-path MIDCOM Agents can be deleted based upon the above
observation.

page 6 - section 2.9: <insert> A </insert> Policy Server is a management....

page 6 - section 2.9 last paragraph:and <insert> the </insert> policy
interface between....

page 6 - section 2.9 last paragraph: is out of  <delete> bounds </delete>
<insert> the scope of </insert> <delete> for </delete> this document.

page 6 - section 2.9 last paragraph a corporate domain is an instance of an
adminstrative domain: <delete> (or corporate) </delete> 

page 6 - section 2.9 last paragraph, next to last sentence: suggested
replacement text "As befitting any end user application, this type of
application specfic policy data is outside of the scope of the Policy Server
considered in this document."

page 8 - figure 1: the MIDCOM Agent co-resident on Proxy Server is a
duplication (an possibly confusing one!) with the MIDCOM Agent on Appl GW.
This is really the same thing - and certainly is if the discussion of
section 2.6 is concluded.

page 8 - section 3.0: The paragraph "Firewall ACLs, NAT-BINDs..."
effectively embeds implementation without a discussion of requirements.
Suggest this paragraph is deleted and figure 1 modified accordlingly as it
prejudices requirements.

page 9 - section 4: This section describes the behaviour of the MIDCOM
protocol and embeds assumed requirements throughout. Suggest this section is
deleted.

page 10 - section 5.0: This section repeates the discussion of in-path and
out-of-path MIDCOM Agents. Suggest this section is deleted and replaced by
incorporated text from Christian's scenarios draft as per the suggestion in
my email to the MIDCOM list of 25th June.

page 13 - section 6.1: This contains a list of assumptions and a mixture of
requirements "... the middlebox MUST not process...." which duplicate a
discussion of requirements in the requirements document and should therefore
be removed from this document.

page 14 - section 6.2: This section contains another string of requirements
concerning the protocol such as "... registration process MUST take
place...". This should be handled as per section 6.1.

page 16 - section 7.0: depending upon the outcome concerning section 2.8 and
4, section 7 can be retitled simply "Illustration of the MIDCOM Framework".

page 17 - section 7.0 last paragraph on the page: this contains a lot of
assumptions concerning the requirements of the MIDCOM protocol concerning
the use of timers. These parts of the paragraph should be removed from this
document.

page 18 - section 7.0 first paragraph on the page: ... stream through.
<insert> The </insert> Policy Server is also <insert> omitted from figure 3
and the associated message sequence charts </insert> <delete> not shown in
the diagram below or on the timelines </delete> for the same reason. {I
think the term message sequence chart is both more technically accurate and
descriptive of the diagrams since this is a more widely understood term and
there is no calibrated time scale on them in anycase.} 

page 18 - section 7.0 last paragraph: typical <insert> message </insert>
<delete> timeline </delete> sequence <insert> for </insert><delete> of
</delete> operations that <insert> may occur between the various elements
involved when establishing a simple telephone call using SIP. </insert>
<delete> transpire with the various elements involved in a SIP telephony
application path.</delete>

page 18 - section 7.1, retitle depending upon the outcome of the comments
above.

page 19 - section 7.2, retitle as per section 7.1

page 23 - section 7.3, retitle as per section 7.1

page 27 - section 8.2, this is a repeat of the issue concerning sections 4
and 6.2.

page 27 - section 8.3 is a requirement and should be deleted from this
document.

page 27 - section 8.4 is conjecture concerning assumed requirements and
should be deleed from this document.

page 28 - section 8.6 forth from last paragraph refers to Q.931. This is not
correct in this context and should refer to the H.225.0 call signalling
protocol.

page 28 - section 8.6 second to last paragraph seems to be repetative and
redundant. Suggest it is deleted.

page 29 - section 9: I have heard the term "Bastion Host" used in this
context and am open to comment as to whether this is preferable to DMZ host.

page 31 - section 12 paragraph 3: this seems to be a tutorial. Is it
necessary here?

page 32 - section 12: there is a mixture of tutorial information, discussion
and requirements in the remaining paragraphs of section 12. In particular
the second and third from last paragraphs state assumed requirements about
the MIDCOM protocol and should be removed from this document.

page 33 - references: the H.323 reference is out of date and should probably
refer to H.323 V4 (2000) unless there was some specific (and not apparent)
reason for referencing H.323 v2.

=== END of comments ====
 
Hope this helps.

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