Subject: RE: [midcom] More bullets

From: "Cedric Aoun" <[email-masked]>
Date: Tue, 2 Oct 2001 16:22:02 +0100

Bob,
Yes synchronization is part of the "how to"s for R23, so I agree to drop R74
Thanks :-)
Cedric

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Tuesday, October 02, 2001 4:45 PM
To: Aoun, Cedric [QPD:MA01:EXCH]; Melinda Shore (E-mail)
Cc: Midcom IETF (E-mail)
Subject: Re: [midcom] More bullets

----- Original Message -----
From: "Cedric Aoun" <[email-masked]>
To: "Melinda Shore (E-mail)" <[email-masked]>
Cc: "Midcom IETF (E-mail)" <[email-masked]>
Sent: Tuesday, October 02, 2001 9:57 AM
Subject: FW: [midcom] More bullets

> Hi Melinda,
> I think that R74 is useful in case the application requires good
> reliability.
> Take the case where 2 redundant Midcom Agents (MA) handles a flows for
> several hundred of
> subscribers. If one MA dies, the other will control the rulesets but you
> need a mechanism
> for the redundant MA (now active) to synchronize states with the
Middlebox.
> I didn't see any requirement covering state synchronization, this could be
> part of the how to do hand-over
> hidden behind R79, but this is not that implicit. Is there anybody in the
WG
> that sees R74 as how to for
> R79?
> We could change R74 to be :
> The midcom protocol MUST allow synchronization of states between the
Midcom
> agent and the Middlebox
Doesn't R23 cover that?

R23: The Midcom Protocol MUST enable the Middlebox and any associated
     Midcom Agents to establish known and stable state.  This must
     include the case of power failure, or other failure, where the
     protocol must ensure that any resources used by a failed element
     can be released.

> Thanks
> Cedric
>
>
> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Thursday, September 27, 2001 9:44 PM
> To: midcom
> Subject: [midcom] More bullets
>
>
> R15: A Midcom agent ought to be able to have a single MIDCOM
>         connection with a middlebox and use the MIDCOM interface on the
>         middlebox to interface with different middlebox functions on the
>         same middlebox interface.
>
> I'd like to drop the trailing "interface" on this one and propose
> keeping this.
>
> R44: The protocol MUST permit the expression of direction to be
>         associated with a pin-hole.  The direction MUST be specified in
>         terms that apply to external view of the Middlebox.  This
>         directionality shall be expressed as 'in', 'out' or 'loopback'
>         (meaning both 'in' and 'out' of the same side of the same
>         Middlebox realm).
>
> The proposal is to drop this: we've already accepted R82, which gives
> broad leeway in descriptions of filtering rules.
>
> R74: A Midcom Agent MUST be able to discover what resources are
>         available on a middlebox.
>
> Proposal: drop.  We've already discussed meaningful error messages.
>
> R68: The Midcom Protocol MUST allow for preservation of the control
>         messages once the association has been established.
>
> Proposal: drop.
>
> Once we get these settled we'll tackle semantics.
>
> Melinda
>
>
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
>

---

From: "Cedric Aoun" <[email-masked]>
Date: Tue, 2 Oct 2001 16:28:17 +0100

I don't have any objections since Bob pointed out that it is under R23.
sorry for the spam :-)
Cedric

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Tuesday, October 02, 2001 5:18 PM
To: Bob Penfield; Aoun, Cedric [QPD:MA01:EXCH]
Cc: Midcom IETF (E-mail)
Subject: Re: [midcom] More bullets

R74 is already dropped.  We won't be reconsidering it.

Melinda