Subject: RE: [midcom] more requirements deletions

From: "Cedric Aoun" <[email-masked]>
Date: Wed, 29 Aug 2001 13:10:52 +0100

I agree that certain requirements needs more clarification:

R75: looks like in case a flow is no longer traversing the same Middle Box,
the Midcom Agent needs to be able to put the same states on another Middle
Box. From a midcom perspective I see this as a requirement where we could
request a Middle box to use certain addresses for the binds to be allocated
so that the networked end parties still send media to the previous ports and
addresses.
I don't know if we have already covered this requirement, I remember that we
had a discussion on the mailing list on the subject

R45: It seemed to me as a vendor could use proprietary functions. right?
this falls more under extensibility. or is it an owner ship (since we are
talking of attributes this seems to be a function support)
If it means extensibility, let's deleted there are other requirements
handling that

R68: does it mean that the protocol should use integrity check mechanism
(either embedded or from a transport layer) to preserve the content of the
message? or does it mean that we need to store the message in memory in case
the other end didn't get the message?
For both interpretations this is not a protocol requirement (we could use
the transport layer to have the integrity check), and the memory is
implementation related issue; to be dumped.

Cedric

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Monday, August 27, 2001 10:56 PM
To: midcom mail-list
Subject: [midcom] more requirements deletions

Hi all,

I have a few more items I think we ought to consider removing or combining.

R23: Isn't this marketing? or just plain motherhood & apple pie?

R75: I'm not sure exactly what this means, but it sounds like a requirement
on the middlebox and the midcom agents to figure out that the routing has
changed and make necessary changes to existing pin-hole rules. How does this
affect the protocol? I propose we remove this requirement.

R45: Does anybody know what this means? It should be clarified or deleted.

R39+R63: These 2 need to be combined since they are basically talking about
response codes. The initial phrase in R63 "To enable management systems to
interact with the Midcom environment" is not needed. The real reason for
useful failure codes is to allow the midcom agent to do something reasonable
in response to the failure.

R68: Do we have new text for this yet?

(-: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