Subject: RE: [midcom] pre-midcom work item

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Sep 2001 12:50:42 -0400

I **>STRONGLY<** support the inclusion of this item into the charter.

Just so people are crystal clear on what this is talkign about, it is
referring to the kind of protocol described in:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-02.txt

Specifically, the "reflector" protocol described there. I have split this
protocol out as a separate, sip independent document, and am working with
some colleagues to finish it up. Expect to see a draft shortly.

Responses to Abdallah inline:

> -----Original Message-----
> From: Abdallah Rayhan [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 11:57 AM
> To: Melinda Shore; [email-masked]
> Subject: Re: [midcom] pre-midcom work item
> 
> 
> I do object adding this to the charter. This is the nail
> that would break what the WG is set to deliver in the
> first place. Interim solutions will be permanent
> once deployed, to start with. 

That is only true when the motivation to upgrade is not there. However, the
solution we are talking about here does not solve the full scope of problems
midcom is solving. In particular: 

* it does not address firewall control
* it has no story around fault tolerance
* it doesn't address twice nat
* it won't work properly in networks with multiple natted egress points

As such, the proposed addition is really targeted at the residential and
small enterprise markets. I think that it will never be acceptable to
carriers or large enterprises, which need a real midcom solution.

These particular markets are also problematic because its not just an issue
of when midcom is finished. The administrator of the nat, in many cases, is
NOT the one who is responsible for delivery of applications. As such, even
if a midcom nat is available, these administrators will not be incented to
upgrade, since there is no reason. The case I always use is that of an
airport Internet lounge, which has a nat. The lounge provides connectivity,
and thats it. They don't care, and may not even know, about apps like VoIP.
They will not be incented to upgrade those nats to midcom enabled ones. We
need solutions for those kinds of scenarios.

> Secondly, this introduces
> new architectural constraints that is going to screw
> the consensus achieved so far on the architecture draft.

How is that?

> Thirdly, this addition to the charter seems to be an
> imposed ad-hoc solution rather than a charter requirement.
> It also suggests that NAT is the only problem which far
> from the truth.

Agreed, which is why midcom remains important. This addition will help us
deal with very very real, very very problematic retail deployment scenarios
which are currently on hold because of NAT. 

> 
> The deployment argument of IKE/IPSec, IP6, MPLS didnt stop 
> the WGs from developing those standards. Why should we be
> the exception?

No one is saying that it should not be deployed. Full steam ahead. We need
midcom, and that hasn't changed. The fact is that midcom can't fully solve
our problems.

Its also worth noting that there are already solutions being deployed today
that play the role of the proposed addition. Those are all proprietary and
not interoperable. Let us not let that continue.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Abdallah Rayhan <[email-masked]>
Date: Mon, 24 Sep 2001 14:21:21 -0400 (EDT)

> > the consensus achieved so far on the architecture draft.

Before amending the charter we at least need to know
what and how this would work. Instead we got a charter
change dictated on us before learning how this 
SIP-happy-NAT is going to influence the current architecture,
or being discussed and scrutinized by the WG.

<snip>
> not interoperable. Let us not let that continue.

What will happen is another beast will be added to the gang.

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca