Subject: RE: [midcom] Midcom proposal: please read

From: "Mary Barnes" <[email-masked]>
Date: Thu, 5 Dec 2002 08:44:45 -0600

Just to clarify, as the Protocol evaluation stands for MIDCOM, it is only
SNMPv3 that is being considered  (based upon the recent -06 version).

Mary

-----Original Message-----
From: Christopher A. Martin [mailto:[email-masked]]
Sent: Wednesday, December 04, 2002 9:46 PM
To: 'Miao Fuyou'; [email-masked]
Subject: RE: [midcom] Midcom proposal: please read

Hi all, sorry I'm late on the thread as usual, 

I agree with SNMP v3 as a potential protocol for this purpose but am not
sure that I agree with the comments about popularity of the earlier
versions ot v3 mentioned below, since I am concerned with security of
midcom implemtation wrt the choice between v1/v2 and v3. I don’t think
that the first two are valid for reasons of message integrity of the
protocol signaling.

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miao Fuyou
Sent: Wednesday, December 04, 2002 9:29 PM
To: [email-masked]
Subject: RE: [midcom] Midcom proposal: please read

If we consider SNMP overall（regardless v1, v2 or v3）as a protocol, I
believe nobody would disagree that it's a widely deployed one. Actually
v3 shares so many features with v1 or v2, which are definitely widely
deployed. What is more, the philosophy and primary architecture behide
them are leave unchanged when it evolved.  So, I think we should
evaluate the effect of v1/v2 popularity to v3 intead of v3 alone. 

BTW, I am new to the WG, the sentences above don't imply any preference.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Wednesday, December 04, 2002 1:13 AM
To: Jerome Moisand; [email-masked]
Subject: Re: [midcom] Midcom proposal: please read

Jerome,

-- Jerome Moisand wrote on 27 November 2002 10:16 -0500:

> Juergen,
>
> I was just saying that choosing SNMPv3 because it's "widely deployed"
> isn't a convincing argument at all.

That's correct.

> I was not making a case for choosing this protocol or against it, I do

> see multiple Pros & Cons for SNMPv3 (and the others).

Agreed.

> I just wanted to express the opinion that we shouldn't shortcut the
> decision-making process.

I would like to shortcut it, but only with good arguments.

> (see below a few more details for clarification, but not really adding

> much to my points).
>
> Tx
> Jerome
>
> ----- Original Message -----
> From: "Juergen Quittek" <[email-masked]>
> To: "Jerome Moisand" <[email-masked]>
> Cc: <[email-masked]>; "Melinda Shore" <[email-masked]>
> Sent: Wednesday, November 27, 2002 9:31 AM
> Subject: Re: [midcom] Midcom proposal: please read
>
>
>> Hi Jerome,
>>
>> I am also not sure whether or not SNMP would be a good choice for
>> MIDCOM. But your arguments confused me. Do you want to say 
>> "everything else would be better? Or do you see a good candidate, you

>> would prefer?
>>
>> Please see some more comments inline.
>
> => and my answers
>
>>
>>     Juergen
>>
>> > Hello,
>> >
>> > I'm new to this list, so apologies in advance if I might repeat
>> > what
> other
>> > people already stated.
>> >
>> > If I remember well, the main point made during the midcom session
>> > about shorcutting the protocol selection process was that SNMP is 
>> > way more
> widely
>> > implemented than other protocol candidates.
>> >
>> > I am not sure to see the value of this point.
>> >
>> > First, SNMP is definitely widely implemented, but essentially for
> monitoring
>> > purposes (alarms & stats). It seems a big stretch to say that SNMP
>> > is
> widely
>> > implemented for provisioning & for authorization, where protocols
>> > like
> CLI
>>
>> Yes, CLI is really most widely implemented as configuration protocol.

>> But this is not at all a protocol (maybe it is 1000 protocols :-).
>
> => I facetiously referred to CLI as a protocol, knowing well that many

> people will balk at this terminology!  ;-) => Yes, we're in complete
> agreement here.
>
>> > and Radius are by far the most widely deployed. Also SNMPv1 and to
>> > a
> lesser
>> > extent SNMPv2 are widely used, but it also seems a big stretch to
>> > say
> that
>> > SNMPv3 is widely implemented. Just look at the largest router
> manufacturer
>> > general strategy in this respect...
>> >
>> > Second, the fact that a protocol is widely implemented doesn't make

>> > it suitable for all purposes. Both Diameter and COPS have been
>> > designed to
>>
>> First you compare SNMPv3 to CLI and say its much less widely used.
>> This is completely right, but not useful at all. Now you compare it 
>> to COPS and Diameter. Compared to Diameter (and probably also COPS), 
>> SNMPv3 is indeed widely used.
>
> => everything is relative, but all in all, none of the proposed
> candidates (SNMPv3 for provisioning, Diameter, COPS) is widely used 
> yet, far from it. By either Network Elements, or OSS systems. Or let's

> say, not to a point where it should become a significant factor in our

> decision-making. These three protocols clearly remain to be proven on
> the field. This is only my perception, of course (probably tainted by 
> the fact that I know well Service Providers environments, but less 
> enterprise networking).

Maybe there is an argument, that SNMP is the protocol which is most
likely to be implemented on a managed box anyway. And in the future, I
expect SNMPv1 and SNMPv2c to be replaced step by step by SNMPv3.

>
>> > allow better processing for transaction-oriented policy decisions
>> > (which
> is
>> > exactly what midcom is about, I believe). Both protocols were
>> > intended
> to
>> > address such situations that SNMP and Radius were not good at. If
>> > it
> were
>>
>> Please exlain! How is COPS addressing the "mutliple clients
>> configuring a single server while addressing the same (kind of) 
>> resources)" situation? I would say: not at all.
>
> => this is another thread of discussion. I did hear Melinda express
> reservations on this point, but this deserves a separate e-mail 
> thread. I'll come back on this, as well as the transaction aspect of 
> midcom (where I think SNMPv3 has a big issue).
>
> => maybe somebody would be kind enough to copy & paste some previous
> e-mail thread on this topic, and forward it to me? Just to not making 
> you guys repeat yourselves?

I'll do so.

>> > not the case, why did IETF spend so much time working on these two
>> > new protocols? Also note that the mere fact that these protocols 
>> > have been recently defined makes it obvious that they are not yet 
>> > widely
> implemented.
>> > So? Should we never use next-gen protocols on this basis? I don't
> believe
>> > so.
>>
>> I cannot follow your argument. We are using a lot of very recent
> protocols,
>> but do we have to choose them always, just because the are new? If
>> COPS-PR is not even widely used in it's original domain, policy-based
> configuration,
>> yet, then why should I already consider using it for other purposes
>> for
> which
>> it was not really designed. The situation would certainly be
>> different, if COPS was already implemented widely for policy-based 
>> configuration of
> devices.
>> But since it is not (and I personally see it coming soon, why should
>> I
> choose
>> it? Because it is 'next-gen'?
>
> => funny the way you took the direct negation of my statement! You're
> saying we should NOT *always* use recent protocols just because they 
> are recent. I was just saying that we should NOT *always* use old 
> protocols (or new flavors of an old protocol) just because they are 
> 'old' (hence 'proven') and have been widely used for a completly 
> different application (e.g. monitoring). Well, both statements are 
> fair, I believe!

agreed.

> => maybe I don't fully understand yet what midcom is about, but I do
> see this as a dynamic policy management problem with transactional 
> properties. So it only seems natural to look at policy management 
> protocols. Which the group rightfully did, without jumping to hasty 
> conclusions. All this sounds fair to me. But suddenly shortcutting 
> such process based on a very debatable point, that, I have to disagree

> with.
>
>> >
>> > Bottomline: I wouldn't understand why such a "decision shortcut"
>> > would
> be
>> > used on the basis of this "wide implementation" argument, which
>> > doesn't
> seem
>> > (to me) to hold much water. I believe the "midcom" group needs to
>> > find a better rationale (and process) for making such decision.
>>
>> On this point, I fully agree with you!
>
> => hey, we did agree on a couple of things, great!  ;-)
>
>> >
>> > Tx
>> > Jerome Moisand (Juniper Networks)
>> >
>> > > Melinda Shore wrote:
>> > >
>> > > > There was a proposal made during the midcom session at the IETF

>> > > > meeting to shortcut the protocol selection process and just go
>> > > > with SNMPv3 as the midcom protocol.  Consistent with IETF 
>> > > > process, this is a decision to be made on the mailing list.  
>> > > > I'd like to come to a decision within the next week or so 
>> > > > (Thursday is Thanksgiving in the US and many people may be away

>> > > > this week).
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Melinda _______________________________________________
>> > > > midcom mailing list
>> > > > [email-masked] https://www1.ietf.org/mailman/listinfo/midcom
>> > > >
>> >
>> >
>> > _______________________________________________
>> > midcom mailing list
>> > [email-masked] https://www1.ietf.org/mailman/listinfo/midcom
>> >
>> --
>
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom

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

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

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