Subject: [midcom] Comments on framework-05

From: "Bob Penfield" <[email-masked]>
Date: Mon, 26 Nov 2001 15:35:03 -0500

Here are my comments (mostly nits) on the framework draft.

1) Section 2: This document should not use RFC 2119 requirements language.
The requirements document doesn't.

2) Figure 2 in section 5 does not show the SIP & RTSP data path outside the
firewall:

                           +-----------+
                           | Middlebox |
                           | Policy    |
                           | Server    |~~~~~~~~~~~~~|
                           +-----------+              \
                                                       \
                    +--------+                          \
                    | SIP    |___                        \
            ________| Proxy  |   \            Middlebox   \
           /        +--------+..  |        +--------------------+
          |                    :  | MIDCOM |           |        |
          |  RTSP +---------+  :..|........| MIDCOM    | POLICY |
      SIP |   ____|  RTSP   |.....|........| PROTOCOL  | INTER- |
          |  /    |  Proxy  |___  |        | INTERFACE | FACE   |
          | |     +---------+   \  \       |--------------------|
          | |                     \  \-----|                    |-----SIP
          | |                      \-------|                    |-----RTSP
          | |                           ---|     FIREWALL       |-->--
         +-----------+                 /---|                    |--<--
        +-----------+|  Data streams  //   +--------------------+
       +-----------+||---------->----//            |
       |end-hosts  ||-----------<-----             .
       +-----------+   (RTP, RTSP data, etc.)      |
                                                   .  Outside the
              Within a private domain              |  private domain

3) section 6.1, 3rd sentence. s/MUST/must/. The framework should not use
RFC-2119 requirements language.

4) section 6.2, 1st sentence. s/MUST/must/. The framework should not use
RFC-2119 requirements language.

5) In section 6.2 it says:
                                        However, it is possible to
   retain the provisioning on middlebox unchanged, by requiring MIDCOM
   agents to initiate the session to middlebox.

Since we have decided that MIDCOM is client-server with the agent initiating
the session, should "by requiring MIDCOM agents to initiate..." be changed
to "since MIDCOM agents initiate..."?

6) Since Out-of-Path agents are out-of-scope, there is no need to qualify
MIDCOM agents as "In-path". Therefore, all occurrences of "In-path" should
be removed from section 7.

7) Figure 3 is not correct. In order to match how it will really work and
the timeline flows it should be:

                         ___________
                     --->|   SIP   |<-----\
                    /    |  Proxy  |       \
                   |     |_________|       |
                  1|       |^    ^|       4|
                   |       ||    ||        |
                   |8     2||3  7||6       |5
   ______________  |       ||    ||        |   ______________
   |            |<-/      _v|____|v____     \->|            |
   | External   |    Na   |           |   Nc   | SIP Phone  |
   | SIP phone  |>------->| Middlebox |>------>| within     |
   |            |<-------<|___________|<------<| Pvt. domain|
   |____________|    Nb                   Nd   |____________|

and the second paragraph should be revised to:

   Arrows 1 and 8 in the figure below refer to SIP call setup
   exchange between the external SIP phone and the SIP proxy.
   Arrows 4 and 5 refer to SIP call setup exchange between the SIP
   proxy and the interior SIP phone and are assumed to be
   traversing the middlebox. Arrows 2,3, 6 and 7 below between the SIP
   proxy and the middlebox refer to MIDCOM communication.

8) Just for correctness, the 100Trying message should precede communication
with the middlebox in all the timeline flows (sections 7.1, 7.2 & 7.3) as
follows:

   SIP Phone      SIP Proxy              Middlebox      SIP Phone
   (External)     (MIDCOM                (FIREWALL      (private)
                   agent)                Service)          |
   |                 |                      |              |
   |----INVITE------>|                      |              |
   |                 |                      |              |
   |<---100Trying----|                      |              |
   |                 |                      |              |
   |                 |+++request to MB+++++>|              |
   |                 |<+response from MB++++|              |
   |                 |                      |              |
   |                 |--------INVITE---------------------->|
   |                 |                      |              |

The 100-Trying response will prevent the External SIP Phone from
re-transmitting the INVITE request when UDP is used.

9) Section 7.2 & 7.3: The "Modify SDP" for the BYE request and the 200-OK
response to the BYE (top of page 24, bottom of page 26 and middle of page
27) should be removed. These messages will not contain SDP.

10) section 9, 3rd para. s/MUST/must/. The framework should not use RFC-2119
requirements language.

11) Several of the items in the REFERENCES section are not explicitly
referenced in the document. H.323, RTSP, FTP, and TLS are mentioned, but
don't have a [] reference. IETF-STD, NAT-COMP, APPL-ID, RFC 1918, RFC 1700,
and REQMTS don't seem to be mentioned at all. Are these just suggested
reading or do they need to be referenced in the text? Also, REQMTS should be
referenced, but should be the latest copy of the requirements draft instead
of Scott's bullet list.

12) The document needs a copyright statement.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

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