Subject: [midcom] London meeting time

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Jul 2001 11:42:19 -0400

We're tentatively scheduled to meet from 9-1130 on Thursday, 9
August.  Also scheduled at that time are:
APP	trade		Internet Open Trading Protocol WG
OPS	rap-II		Resource Allocation Protocol WG
SEC	sacred		Securely Available Credentials WG
SUB-IP	tewg		Internet Traffic Engineering WG
TSV	avt-II		Audio/Video Transport WG

At the top of the agenda are wrapping up those things which need
to be wrapped in the framework document and the requirements
document.  Please let me know if there's anything you feel *must*
be addressed in the meeting beyond work on the documents.

Note, however, that it would be very, very, very much appreciated
if issues could be raised on the mailing list ahead of time - the
meeting is not *the* place where work is done, but one place
among several.  The bulk of the work is done on mailing lists, and
that's where consensus is developed.

Also, as we prepare to go into last call on the framework document,
do raise issues as soon as you become aware of them rather than
waiting until the last minute and gumming up the process.  Many
thanks.

Melinda

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

---

From: "Cedric Aoun" <[email-masked]>
Date: Wed, 11 Jul 2001 23:00:54 +0100

On 11 Jul 2001 at 12:28 +0100, Cedric Aoun apparently wrote:
> I would really want us to discuss during the session how the extensibility
> of the Midcom protocol
> could be achieved to take into account other Middle Box functions. I'm
sure
> that some of us (WG members) are
> looking for that. I don't think that people want to see another WG being
> created to take into account other Middlebox functions.

Cedric, first of all, this mailing list is the main session.  The
physical meetings are (imo) mainly to work out details which we fail to
work out in mail.  Bring up issues here.  Type a lot.

CA>Scott, I was mentioning that as part of the potential discussions for our

session in London. I was preferring that we discuss the extensibility 
after 51 on the list. This is MAINLY to maintain the focus on delivery of
our 2 documents on time.
I completely agree with you, more than 95% should be done in the list since
we 
have 7.5 h per year where we discuss face to face.

> The only problem is that how can we talk about the tools to achieve the
> extensibility
> if we didn't even finish the protocol requirements and started look at
what
> existing protocol (with some extensions) Midcom should be.

Right.  We really need to look at real life requirements.  How
extensible does this protocol actually need to be?  How much will each
level of extensibility cost us in terms of robustness, security, etc.?

CA>What I meant by extensibility is how can we make MIDCOM request other
functions from the Middle Box?
Currently we only thought about Qos as being one of other functions that the
Middle Box
could handle. Packet diversion for legal intercept reasons might be another
one (but I didn't hear
anybody mentioning that one).
How can we add these functions without major changes in the Midcom protocol?
That's why I mentioned usage of packages or policy objects to do that.

> The extensibility could be achieved by a package (Megaco, MGCP way) or
> policy objects like with RSVP; I think we need to dig a little bit 
> on this.

I understand the objects/elements approach.  I don't know what you mean
by using a "package".

CA>Apologies for the confuse that this brought, a package is also an object
it has a descriptor and properties for each 
parameter of the descriptor. 
I used the term package due to a potential usage of device control protocols
such as Megaco to be the Midcom protocol.

> There is another thing that we discussed briefly on the mailing list
(emails
> between Andrew and Melinda) but didn't seem to move further:
> What is our definition of connection setup between the Midcom Agent and
the
> Middlebox?

How does this sound for a summary (inspired by Christian, Suresh and
others)?  The relationship between agent and middlebox should be
stateless.  "Setup" consists merely of authentication & authorization of
the middlebox, and version/parameter negotiations (as you mention) such
as establishment of how transactions will be signed, possible
encryption, etc.  There is no further state necessary or wanted.  In
order to make this possible, all transactions should be in absolute
terms (e.g. absolute expiration times for pinholes).  No particular
agent should "own" a pinhole or any other installed rule -- if an agent
is authorized to manipulate a rule then that agent can do so.  Agent
authorization should be as specific as necessary to support this.
Conflicts and confusion between battling agents should not be resolved
by complex state in the middlebox and notifications, but rather by
interactions between the agents themselves.  This keeps the middlebox
clean.

CA>This sounds reasonable, but I don't think I have seen it that way in the
fmwrk or
the protocol reqs documents.
Cedric

...Scott

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Jul 2001 14:51:32 -0400

At 02:28 PM 7/12/01 -0400, Fernando Cuervo wrote:
>There are two separate issues around the choice of transport: 
>1-security implications: If TCP and UDP are to be allowed then a security element in the protocol or use IPSec are needed
>
>2-transaction capabilities: given that the issue is reliability the use of UDP requires that timers and retransmissions to be handled by the protocol. However, regardless of TCP or UDP things such as transaction in progress or even an abort command (to handle the open/close pin-hole scenario) may be useful, therefore it would be wise to leave all transaction control to the protocol, which is compatible with the dual use of TCP and UDP.

Not to be tiresome, but we are not choosing a transport.  We need
to describe the characteristics we require of the transport.

Melinda

---

From: "Fleischman, Eric W" <[email-masked]>
Date: Thu, 12 Jul 2001 13:15:33 -0700

It isn't clear to me what a "transaction" means to the Midcom WG. 
My own use of the term is directly influenced by application 
layer concerns and explicitly includes two phased commits (e.g., for 
databases and transactional systems). But some may use the term in 
the sense of "agreement instance between the midcom agent and the 
middlebox". Which meaning is being used here? Specifically, are 
we proposing that two-phased commit semantics be used for Midcom? 
If so, why?

---

From: "Fernando Cuervo" <[email-masked]>
Date: Mon, 16 Jul 2001 10:24:10 -0400

I'm using the transaction term in the sense of a request-reply mechanism
that can in
addition provide "in-progress" status or accept "abort" commands. Further a 
transaction may contain several service request to a midcom box that may
need to be
processed together or not at all.

Fernando Cuervo

> From:	Fleischman, Eric W [SMTP:[email-masked]]
> Sent:	Thursday, July 12, 2001 4:16 PM
> To:	Cuervo, Fernando [CAR:5N10:EXCH]; 'Christian Huitema'; Andrew
> Molitor; midcom
> 1-security implications: If TCP and UDP are to be allowed then a security
> element in the protocol or use IPSec are needed
> 2-transaction capabilities: given that the issue is reliability the use of
> UDP requires that timers and retransmissions to be handled by the
> protocol. However, regardless of TCP or UDP things such as transaction in
> progress or even an abort command (to handle the open/close pin-hole
> scenario) may be useful, therefore it would be wise to leave all
> transaction control to the protocol, which is compatible with the dual use
> of TCP and UDP.
>

---

From: "Fernando Cuervo" <[email-masked]>
Date: Mon, 16 Jul 2001 10:24:23 -0400

SCTP is an interesting alternative, I have not kept up with the details, but
a way back when
Megaco and SCTP we emerging this seemed to me a reasonable way to handle the
transaction
requirements...It's probably worth looking into it.

Fernando Cuervo

> From:	Scott Brim [SMTP:[email-masked]]
> Sent:	Thursday, July 12, 2001 3:25 PM
> To:	Cuervo, Fernando [CAR:5N10:EXCH]
> Cc:	'Christian Huitema'; Andrew Molitor; midcom
> What about SCTP?

---

From: "Fernando Cuervo" <[email-masked]>
Date: Mon, 16 Jul 2001 10:24:04 -0400

Let me put it this way... the transaction requirements level the playing
field for TCP vs. UDP.
Implementing both will give you more choice for security mechanisms. I agree
with Christian's 
concern about fragmentation...how we handle fragmentation might be the
deciding factor...

Fernando Cuervo
> From:	Melinda Shore [SMTP:[email-masked]]
> Sent:	Thursday, July 12, 2001 2:52 PM
> >2-transaction capabilities: given that the issue is reliability the use
> of UDP requires that timers and retransmissions to be handled by the