Subject: RE: [midcom] Time for a Time-Out?

From: "Mary Barnes" <[email-masked]>
Date: Fri, 6 Dec 2002 10:46:25 -0600

Per my response to the SNMP thread earlier this morning, I can't say that I
disagree with Jonathan's views and my prioritization of his suggestions for
ideas on going forward would be similar. I would put 1 (let the market
decide) or 5 (new protocol) first.  However, I would think 2 (leave it
proprietary) would be preferable to 4 (dictated by IESG), since I would
think alot of existing 2's are some variation on the proposed 1s or the new
protocols (5s).  Option 3 (IRTF) might have been a good choice coming out of
the foglamps bof, but I think it's way too late for that or we could do 3,
obviously in parallel with 2. 

Mary. 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, December 06, 2002 10:24 AM
To: Eric Burger
Cc: IETF Midcom (E-mail)
Subject: Re: [midcom] Time for a Time-Out?

I've personally been silent on all of this stuff for quite some time. To 
  be honest, that is primarily due to my frustration at the general lack 
of progress and amazing circuitousness (is that a word) of the path we 
have taken to completion of this work.

Some responses inline.

Eric Burger wrote:

 > Last time I looked, the IETF is the organization that does protocols.
 > Why do we have this aversion to creating a protocol?  Because of
 > marketplace realities, I have to build a proprietary protocol to make
 > something that works and scales.
 >
 > Now let's look at midcom and progress to date.  It has been over a
 > year,

Oh, much longer than that. I recall the foglamps bof meeting in Adelaide 
in March 2000, which is almost three years ago. Most groups produce real 
protocols in faster than three years after their bof.

 > and the work group really hasn't produced anything of
 > substance.  There is still discussion on the list about the
 > requirements.  At the rate we're going, I don't expect that we will
 > produce anything in the coming year, either.

I agree.

I think it is time for a change in direction. Right now, we are on a 
path to fail. There are folks in each protocol camp who will clearly not 
budge. There is also, I think, a good contingent (myself included) who 
would rather build a new, simple-as-possible protocol for the task at 
hand. There is also a large contingent that is tired and no longer 
cares. Indeed, the participation in list discussion has dropped 
tremendously since this evaluation process began. Where is everyone?

I would like to propose that the group consider some radical actions at 
this point. Short of that, we will probbaly fail to produce anything at all.

I do not know what the right thing is, but here are some ideas:

1. Parallelism, ala IMPP: Let the COPS people, SNMP people, and new 
protocol people all develop their own protocols. Make the semantics doc 
a mandatory thing, so that each protocol must provide the semantics 
described there, and show a mapping. THis is akin to the CPIM approach. 
THen, let the market pick a winner. Three is better than zero, I guess.

2. Shut down: Just give up. Close the group. This interface remains 
proprietary. We have things like TURN, ALGs and eventually nsis, which 
is (I think) the right answer. Of course nsis is probably 5 years away 
from useful deployment.

3. Move to IRTF: As Eric suggests.

4. Dictatorial Fiat: The IESG tells the group to "use protocol X" and we 
do that (seems unlikely but I throw it out for consideration).

5. New protocol: do a new one from scratch.

Other ideas? I would favor approach 5 first, then 1, then 4, then 2, 
then 3.

-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]
https://www1.ietf.org/mailman/listinfo/midcom
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Durham, David" <[email-masked]>
Date: Fri, 6 Dec 2002 10:14:50 -0800

Hi Melinda,

I think you should find some resolve in noting that PIBs and MIBs are much
more alike than different. It's really just a protocol issue, I think the wg
would be safe on the data model front with either COPS-PR or SNMP (a two for
one?). In the case of megaco & diameter, however, the data models are
fundamentally different. 

-Dave

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 8:37 AM
> To: Jonathan Rosenberg
> Cc: Eric Burger; IETF Midcom (E-mail)
> I can think of at least four existing "from scratch" midcom
> protcols, and I don't see the process of sorting through
> them as being any easier than sorting through COPS, SNMP,
> megaco, and Diameter.
> 
> Melinda

---

From: "Moisand, Jerome" <[email-masked]>
Date: Fri, 6 Dec 2002 14:28:15 -0500

Jonathan, thanks for the reset & suggested approaches. Great idea. My view:

1. seems the way to go to me. Let people volunteer to extend existing
SNMP-MIB & COPS-PIBs & Diameter-attributes to add NAT/FW rules (if missing
from existing ipsp work). Or define new xIBs. If no volunteer for one
protocol, well, be it. Maybe request at least reps from two
companies/organizations as authors, just as a minimal check of industry
support. Last but not least, allow maximum flexibility in architectures by
helping a diverse approach.  

2. don't think we should give up, this work is definitely useful. This being
said, I'm wondering if this work would not benefit from being regrouped with
some other IETF activities (e.g. ipsp and/or nsis).

3. seems even more circuitous than what happened in the past, isn't it?
;-)

4. er... I have reservations about a dictatorial process...

5. sounds to me that we suffer from having too many candidates as opposed to
not enough. So I'm not sure why we'd reinvent the wheel. Also I can't
reemphasize enough the importance of the "be part and be consistent with a
bigger picture" goal, which implies to reuse some existing protocol
infrastructure and benefit from existing information models. 

Tx
Jerome

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, December 06, 2002 11:24 AM
To: Eric Burger
Cc: IETF Midcom (E-mail)
Subject: Re: [midcom] Time for a Time-Out?

[...]

-Jonathan R.

---

From: "Cedric Aoun" <[email-masked]>
Date: Tue, 10 Dec 2002 19:08:08 +0100

I agree with you.

I know we're all tired of discussing this and not delivering a protocol
since the Adelaide meeting (Summer 2000), but what's the point of delivering
something if we find out later that it is not applicable (ref to the
dictatorial option 4 that you have referenced below)? 

Here's my preferred ranking on moving forward options that you have stated
below:
1,5,2,4 and finally 3

The protocol being elected from 1 might end up being tailored a bit (either
MIB, PIB or other if it is a new protocol) so there is a step 6 actually to
tailor it.

In addition in case the WG is not aware, there seems to be a lot of effort
in the IETF to move to XML for configuration, should we interpret this as
using SNMPv3 for MIDCOM as a risk?
Thanks

Cedric 

> I've personally been silent on all of this stuff for quite some time. 
> To  be honest, that is primarily due to my frustration at the general 
> lack of progress and amazing circuitousness (is that a word) of the 
> path we have taken to completion of this work.
>
> Some responses inline.
>
> Eric Burger wrote:
>
> Oh, much longer than that. I recall the foglamps bof meeting in 
> Adelaide in March 2000, which is almost three years ago. Most groups 
> produce real protocols in faster than three years after their bof.
>
> path to fail. There are folks in each protocol camp who will clearly 
> not budge. There is also, I think, a good contingent (myself included) 
> who would rather build a new, simple-as-possible protocol for the task 
> at hand. There is also a large contingent that is tired and no longer 
> I would like to propose that the group consider some radical actions 
> at this point. Short of that, we will probbaly fail to produce 
> anything at all.
>
> protocol people all develop their own protocols. Make the semantics 
> doc a mandatory thing, so that each protocol must provide the 
> semantics described there, and show a mapping. THis is akin to the 
> CPIM approach. THen, let the market pick a winner. Three is better 
> than zero, I guess.
>
> 4. Dictatorial Fiat: The IESG tells the group to "use protocol X" and 
> we do that (seems unlikely but I throw it out for consideration).
>