Subject: [midcom] new bullets text

From: Scott Brim <[email-masked]>
Date: Tue, 25 Sep 2001 09:45:36 -0400

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

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 25 Sep 2001 10:26:38 -0400

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]

---

From: Mark Duffy <[email-masked]>
Date: Tue, 25 Sep 2001 11:21:04 -0400

>         more than one Midcom agent simultaneously.

Agreed.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 25 Sep 2001 11:34:42 -0400

>>         more than one Midcom agent simultaneously.

A couple of things: 1) if everybody starts proposing stuff
off the list it will work against making progress, and 2) 
have a good hard think about these and what they actually 
mean for protocol design.  I haven't brought these up yet
because I've been trying to get through the obvious stuff
and these are decidedly not obvious.

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 25 Sep 2001 12:54:43 -0400

I'm sorry if I jumped the gun, but at the moment there are only 7 items
listed in the "Requirements Under Discussion" section of the bullet list,
and I think these are the most obvious. I have been thinking about these
particular requirements for several months. I think there has been general
agreement on these requirements as they are currently stated. I believe the
rewording of these was based on input from many people.

(-:bob

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

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Mark Duffy" <[email-masked]>; "midcom mail-list"
<[email-masked]>
Sent: Tuesday, September 25, 2001 11:34 AM
Subject: Re: [midcom] accept R3a1 & R3a2

---

From: Melinda Shore <[email-masked]>
Date: Tue, 25 Sep 2001 14:08:46 -0400

>rewording of these was based on input from many people.

I think that we need to be clearer about what specific demands
this places on the protocol and perhaps include those demands
rather than what's currently in there.  I think the elements that
would be required to do this may actually be in there already.
Getting this wrong could potentially lead to a NAT-unfriendly
protocol.  Really, think about what would be required *of a protocol*
for a single agent to talk to multiple middleboxes and see what's
currently missing from the current requirements.  As stated, R3a1
and R3a2 have virtually no discriminatory value.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Tue, 25 Sep 2001 22:34:04 -0400

>and R3a2 have virtually no discriminatory value.

Melinda, could you elaborate a bit on what dangers you see here?  These two
seem so fundamental to me that they almost don't need to be stated (but I
think they should be).

-Mark

P.S. both of them might impose some substantive effects on the protocol
design if they are construed to include the cases of multiple
middleboxes/agents (respectively) residing in the same physical box and
having the same IP address.  I could see that we might want to clarify
them, or add other requirements to clarify, whether multiple logical
middleboxes/agents at one IP address need to be supported.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 26 Sep 2001 09:13:33 -0400

>seem so fundamental to me that they almost don't need to be stated (but I

Okay - as stated the "requirements" are too vague and decidedly
not useful for protocol selection.  The things that need to be
done to support the "requirements" are actually the requirements,
and I'm not sure that anything needs to be done.  My concern is
that mishandling this could lead to something we obviously don't
want, like protocol-embedded IP addresses.

>having the same IP address. 

I *really* don't want to see the protocol design being driven by
pathological cases.

Melinda

---

From: Scott Brim <[email-masked]>
Date: Wed, 26 Sep 2001 09:40:05 -0400

> I *really* don't want to see the protocol design being driven by

Would 'must operate through a NAT' be a pathological case?

---

From: Mark Duffy <[email-masked]>
Date: Wed, 26 Sep 2001 09:55:34 -0400

>done to support the "requirements" are actually the requirements,

I'm not sure what you mean by that.  Do you mean that R3a1/2 should be
rewritten to state *how* to accomplish what they currently say???? (I
suspect not.)  These don't seem vague to me either.  Do you have a specific
rewording to suggest?

>I *really* don't want to see the protocol design being driven by

Fine by me to explicitly not require support for such cases.

Mark

---

From: Melinda Shore <[email-masked]>
Date: Wed, 26 Sep 2001 10:11:46 -0400

>Would 'must operate through a NAT' be a pathological case?

The presence of more than one NAT is not that uncommon, 
unfortunately.  I've personally never heard of multiple 
middleboxes sharing a single address, other than failover
scenarios or clustering, where routing is handled at a 
lower layer.  Are there such things?  As I said, it is not
my impression that much thought has been given to what
this requirement actually means for protocol design.  I
think we're covered.

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 26 Sep 2001 10:30:55 -0400

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Mark Duffy" <[email-masked]>; "midcom mail-list"
<[email-masked]>
Sent: Wednesday, September 26, 2001 9:13 AM
Subject: Re: [midcom] accept R3a1 & R3a2

> want, like protocol-embedded IP addresses.
By protocol-embeddded IP addresses, I assume that you are talking about the
addresses of the agent and the middlebox. Maybe we need to explicity state
that we don't want those addresses embedded in the protocol. Given that the
whole idea of midcom arose because so many application protocols have
embedded addresses, relying on protocol-embedded addresses of the agent &
the middlebox in the midcom protocol would be the last thing we would do.

I like Mark see the ability of a midcom agent having midcom sessions with
multiple middleboxes and multiple midcom agents having midcom sessions with
one middlebox as fundamental. I think these requirements are here so that we
don't pick a solution that allows for only a single midcom agent talking to
a single middlebox.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 26 Sep 2001 10:44:36 -0400

>don't pick a solution that allows for only a single midcom agent talking to

Okay, there does seem to be consensus on this.  I do think
that these are not useful requirements as stated, I do think
that we're already covered on this, and I've received guidance 
from an AD that these requirements don't impart thrill, but I 
have no doubt that someone will step forward to defend this decision 
when it gets tossed back at us by the IESG.  Let's accept them.

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 26 Sep 2001 07:56:26 -0700 (PDT)

> want, like protocol-embedded IP addresses.

I dont understand your concern about "protocol-embedded IP address". 
The MIDCOM sessions are bound to have IP addresses embedded for
control/signaling/query purposes. Why do we not want that?

Secondly, how is this concern related to R3a1 & R3a2? 
As ohers pointed out, R3a1 and R3a2 seem rather straight
forward and obvious requirements to me.
 
regards,
suresh

=====

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Sep 2001 10:56:55 -0400

> Given that the
> embedded addresses

no, the whole idea of midcom was a desperate attempt to make a few
more applications work through NATs.  but NATs cause problems for a
great many more applications than those that have embedded addresses.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Wed, 26 Sep 2001 11:05:56 -0400

>control/signaling/query purposes. Why do we not want that?

Transporting an address to be installed as a NAT table
mapping is not the same as using what should be a transport
address to demultiplex endpoints.

>forward and obvious requirements to me.

We're in motherhood and apple pie-land here.  Additionally, these 
requirements as stated do not help distinguish among candidate 
protocols, and there are other mechanisms already in there (like 
transport addresses, which are implicit in any network communication, 
along with transaction or resource identifiers).

These are two very, very low-quality requirements.  Nevertheless, 
we have consensus.  Let's move on.

Melinda