RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06]

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

This discussion has for me some confusing aspects. The existence of
several management protocols is not something new. After all most of the
devices that I know 'always' supported at least two management protocols
- CLI and SNMP - now COPS emerged for policy configuration on some
devices, and there are several other around. 

I am not sure that the requirement of not duplicating information is
caught in any of the standards. It is more a common sense requirement,
but behind it hides the more complex issue of a single data model for
all IETF management protocols. This is the real issue that we need to
face as we advance towards the 'new generation' of management protocols,
and in the absence of a valid solution to this problem no real
consistence can be expected in this space.

Before Brian jumps on me, I would say that this discussion might be
appropriate for one of the 'management - new generation' lists, but
before we move there (if anybody is interested in the continuation of a
thread on this) I wanted to have the reply visible for the participants
in the original thread.

Regards,

Dan


> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Monday, February 04, 2002 12:54 PM
> To: Kwok Ho Chan; rap@ops.ietf.org; diffserv@ietf.org
> Cc: saurabh.kapoor@wipro.com; srinivasu.nampelli@wipro.com; 
> ravi.attili@wipro.com; naganna.vydyula@wipro.com; 
> krishna.akkineni@wipro.com
> Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and 
> Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06]
> 
> 
> Kwok writes:
> > 
> > An alternative to the treatment of ifSpeed by the DiffServ PIB is to
> > add an attribute qosIfSchedulerCapsIfSpeed to 
> qosIfSchedulerCapsEntry
> > to indicate the bit rate that can "sink" the output of the Scheduler
> > Data Path Element.  This will allow the DiffServ PIB to not 
> > rely on the Interface MIB.
> > 
> So to me that sounds as "duplicating" information. 
> How does this new field get filled out by the PEP?
> What if that field conflicts with ifSpeed?
> 
> Would any network device not have the IF-MIB implemented anyway,
> so the fact that you remove the dependency from the PIB, does not
> mean that the IF-MIB does not have to be implemented in the device,
> does it?
> 
> Bert
> 
>