Re: [Diffserv] RE: why i should like pibs

[Brian E Carpenter <brian@hursley.ibm.com>]

[ post by non-subscriber ]

Let's try to stick to technical issues please, at least if
you want to keep the diffserv list on this thread.

The technical issue is: does COPS-PR have *significant* technical
advantages over the existing alternatives, that would justify
the added mechanisms and complexity?

   Brian

"Yavatkar, Raj" wrote:
> 
> Hi Walter:
> 
> Thanks for a really nice summary. I continue to be amazed at how Randy is
> applying a set of inconsistent standards to this work vs other work being
> done. Rob Coltun put the current state of IETF well in his departing message
> -- I was hoping that would wake up IESG to move away from such political
> shenanigans to getting work done especially when vendors with products or
> implementations are working towards standardization.
> 
> Raj
> 
> -----Original Message-----
> From: Weiss, Walter [mailto:wweiss@Ellacoya.com]
> Sent: Monday, March 18, 2002 11:45 AM
> To: 'Randy Bush'; rap@ops.ietf.org; diffserv@ietf.org
> Cc: ipsec-policy@vpnc.org
> Subject: [Diffserv] RE: why i should like pibs
> 
> Randy,
> 
> I have two responses.
> 
> 1. Political:
> Why are you asking? Why do you keep asking? And more importantly why, based
> on your criteria, haven't you asked for every non-monitoring MIB, or for
> various other works such as Policy Framework. I don't mind if we want to
> have a substantive discussion around the evolution of configuration
> management if you applied your own metrics consistently. If you believe that
> none of these technologies meet's your requirements, then freeze them all.
> At least then there will be some pressure on all the parties to converge to
> a common approach. Personally, I believe your question is a waste of time
> since the existing IETF process addresses your question when there is
> sufficient implementation to transition standards from proposed standards to
> draft standards. Certainly there have been lot's of standards that have
> never made it past proposed for the very reasons you describe.
> 
> 2. Technical:
> Given your role, I would not expect you to use this PIB. The very argument
> justifying DiffServ is the same one that Operators use to manage their
> networks. Both share the goal of making the core of the network static and
> stupid (minimal configuration). By recognizing that the core should be kept
> as simple as possible, we also all understand that removing complexity from
> the core only moves the complexity to some other location: the edge. If the
> edge must configure bindings of QoS, Security, Access Control, Tunneling,
> Usage Accounting, etc, this drives specific requirements that COPS-PR comes
> closest to meeting. I could go into all the details here, but given that
> this thread inevitably de-evolves to the usual suspects and the usual
> posturing, I have serious doubts about the value of going into any more
> details.
> 
> regards,
> 
> -Walter
> 
> > -----Original Message-----
> > From: Randy Bush [mailto:randy@psg.com]
> > Sent: Monday, March 18, 2002 9:13 AM
> > To: rap@ops.ietf.org; diffserv@ietf.org
> > Cc: ipsec-policy@vpnc.org
> > Subject: why i should like pibs
> >
> >
> > wearing my iesg hat but being just a stupid operator, i am trying to
> > understand the pib/mib controversy.  fyi, i currently use snmp heavily
> > for monitoring devices on my network.  i configure using
> > large db-driven
> > code and spew text-based cli to the devices.
> >
> > let's assume i want to take the leap to a binary, as opposed
> > to textual,
> > configuration language.  i.e. for some reason(s) [which we will PLEASE
> > NOT discuss here] i decide to move from pushing text-based cli configs
> > out to pushing a binary format.
> >
> > hence, i would have to push my vendors to implement snmp/cops
> > writes for
> > all configuration aspects of all devices.  this would be big cost for
> > both me and for my vendors.
> >
> > why would cops/pibs be significantly better (remember it has
> > to replace
> > my current investment, so it can not be 'just as good') than
> > snmp/mibs?
> >
> > randy