Subject: RE: [midcom] Where we stand/SNMPv3

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 12 Dec 2002 14:55:11 -0500

I actually figured I had to develop the MIB this week to make sure SNMP is a
feasible approach.  I was working on the assumption that the MIB to be
developed represents the Agent's view rather than the view of the Middlebox.
(i.e.) the Middlebox will have to maintain a MIB which is more extensive
than what the Agent gets to see and manipulate.

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]] 
> Sent: Thursday, December 12, 2002 2:13 PM
> To: [email-masked]
> Subject: [midcom] Where we stand/SNMPv3
> 
> 
> As things currently stand the two concerns raised regarding 
> using SNMPv3 as the midcom protocol are 1) lack of interface 
> to a keying infrastructure, and 2) questions about 
> transaction rate.  The first is clearly addressable and the 
> second, I think, remains an open question.  We don't have a 
> show-stopper. 
> 
> This process (working through the list in the order
> presented in the evaluation document) is about coming to a 
> decision, but not coming to a consensus-based decision. It's 
> absolutely clear that putting the three remaining protocols 
> in front of the working group and saying "pick one" wasn't 
> going to produce a consensus decision, either. In fact it was 
> pretty much guaranteed to produce *no* decision.  One 
> interested observer described the process as the working 
> group being in a death spiral, and I don't think the choice 
> of the word "death" was accidental (more on that below).
> 
> There seems to be an assumption among some working group 
> participants that if we eliminate all of the existing 
> protocols from contention we will be rechartered to undertake 
> development of a protocol from scratch.  That is absolutely 
> not the case.  I think it's pretty clear that if we found 
> that none of SNMP, Diameter, and COPS were suitable the 
> working group would be terminated rather than rechartered.  
> We were told that eliminating them was a precondition for 
> doing one from scratch, but we were never, ever told that if 
> we were able to do so we would be given carte blanche to 
> develop a new protocol.
> 
> That leaves us with these questions: given that we did not 
> arrive at SNMPv3 by consensus and given that the likely 
> alternative is folding up our tent, is there support for 
> going ahead and developing a midcom MIB and keying framework 
> for SNMPv3?  Is this something that would be useful and 
> deployable?  Are there people who would be interested in 
> doing the work?
> 
> Melinda
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
>

---

From: "Harrington, David" <[email-masked]>
Date: Thu, 12 Dec 2002 16:20:56 -0500

I assumed that we would pick one, then take some time to design a
solution with it. If it turns out that the chosen protocol doesn't work,
then we eliminate it from contention and go back to the remaining
candidates.
 
I doubt that we could design a well-designed solution with any candidate
protocol, given only one day to do it.
 
dbh

	-----Original Message-----
	From: Tom-PT Taylor [mailto:[email-masked]] 
	Sent: Thursday, December 12, 2002 2:55 PM
	To: 'Melinda Shore'; [email-masked]
	Subject: RE: [midcom] Where we stand/SNMPv3

	I actually figured I had to develop the MIB this week to make
sure SNMP is a feasible approach.  I was working on the assumption that
the MIB to be developed represents the Agent's view rather than the view
of the Middlebox.  (i.e.) the Middlebox will have to maintain a MIB
which is more extensive than what the Agent gets to see and manipulate.

---

From: "Moisand, Jerome" <[email-masked]>
Date: Fri, 13 Dec 2002 13:08:50 -0500

I'm glad you clarified, Melinda. I have to say I'm very uncomfortable with
the "non-consensus" approach. In the five approaches suggested by Jonathan,
I don't believe there was much support for this one... And I don't believe
this is the best way to make the "midcom" protocol a reality implemented by
multiple players.

Maybe I'm still pretty new to the workgroup, but personally, I'm not
convinced we were in a "death spiral". The list of protocols was getting
slimmed down. And maybe I'm mistaken, but somehow I believe we could have
quickly reached a "two protocol" list.

What I cannot understand is why we did not consider the proposal to work on
two protocols IF there were enough volunteers (hence industry interest) to
do one or the other. 

As a personal assessment, I persist to think that SNMP is a better match for
some scenarios/architectures, and COPS is a better match for some
scenarios/architectures. I also strongly believe that the "spiral" we've
entered tends to show that a single protocol approach is not the right thing
to do, because the argument seems to have lasted long enough that each
"camp" must have had valid points...

The diffserv group developed a MIB and a PIB. The ipsp group is doing the
same. And well, for these respective domains (both of them somewhat
intersecting the midcom work, by the way), I think this was the right choice
to allow architectural flexibility and provide the best answer to a large
collection of use cases.

As to the midcom group "efficiency" question, I do agree that working on
something "real" (an SNMP MIB, a COPS PIB, whatever) is the way to move on.
Then we stop with all these endless theoretical arguments and ask ourselves
the real questions about the actual mapping, how to do it, does it work.

Just my two cents...

Jerome

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 2:13 PM
To: [email-masked]
Subject: [midcom] Where we stand/SNMPv3

[...]

This process (working through the list in the order
presented in the evaluation document) is about coming to a
decision, but not coming to a consensus-based decision.
It's absolutely clear that putting the three remaining
protocols in front of the working group and saying "pick
one" wasn't going to produce a consensus decision, either.
In fact it was pretty much guaranteed to produce *no*
decision.  One interested observer described the process as
the working group being in a death spiral, and I don't think
the choice of the word "death" was accidental (more on that
below).

There seems to be an assumption among some working group
participants that if we eliminate all of the existing
protocols from contention we will be rechartered to
undertake development of a protocol from scratch.  That is
absolutely not the case.  I think it's pretty clear that if
we found that none of SNMP, Diameter, and COPS were suitable
the working group would be terminated rather than
rechartered.  We were told that eliminating them was a
precondition for doing one from scratch, but we were never,
ever told that if we were able to do so we would be given
carte blanche to develop a new protocol.

Melinda