Subject: RE: [midcom] accept R3a1 & R3a2

From: "Sanjoy Sen" <[email-masked]>
Date: Tue, 25 Sep 2001 10:33:47 -0500

Agreed.

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2001 9:27 AM
> To: midcom mail-list
> Subject: [midcom] accept R3a1 & R3a2
> 
> 
> In the interest of continued progress, I propose that we 
> accept R3a1 and
> R3a2.
> 
>    R3a1: The Midcom protocol MUST allow a Midcom agent to communicate
>          with more than one middleboxes simultaneously.
> 
>    R3a2: The Midcom protocol MUST allow a middlebox to 
> communicate with
>          more than one Midcom agent simultaneously.
> 
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> [email-masked]
> 
> ----- Original Message -----
> From: "Scott Brim" <[email-masked]>
> To: "midcom mail-list" <[email-masked]>
> Sent: Tuesday, September 25, 2001 9:45 AM
> Subject: [midcom] new bullets text
> 
> 
> > Bullets -010924.txt is now available at
> > <http://www.employees.org/~swb/midcom.html>.
> >
> > R1a accepted.
> > R32 revised and accepted.
> > R10 deleted in favor of R32.
> > R13 deleted.
> > R14 deleted.
> > R40 deleted in favor of R82.
> >
> > Progress is being made.
> >
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/midcom
> >
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
>

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 26 Sep 2001 18:33:24 -0700

> > If there is a requirement, it is that the Midcom client can
> establish a
> > connection to the server securely, even if there are one or several
> > middlemunglers between the client and that specific server. However,
> we
> > should be clear that the client is expected to describe packets
> exactly
> > as they are seen by the controlled middlebox, and that we are
> certainly
> > not supporting, let alone requiring, that the intermediates rewrite
> the
> > MIDCOM packets. In practical deployment cases, I expect the
> > communication between client and server to be encrypted.
> 
> A far-fetched scenario:
> 
> agent----NAT1---FW1--NAT2----FW2-----...
> 
> If the agent has to control all these, how does it know the correct
> order in which they should be contacted?

This is a discovery issue. Discovery is out of scope.

-- Christian Huitema