RE: docsis subscriber mib

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Possibly... the reason why I forwarded was,
cause they seem to want one common way of doing these
things and we/they already have a set of RFCs that
do this in the same way as they are proposing in this 
new MIB module. 

So the question becomes:
 - is it so seriously flawed that we want to force them 
   to change the way they are doing these resets
 - if so, then we should make a note so that if they
   respind the existing RFCs, that we then also force them
   to deprecate and create a new object.

Or does this not make sense what I am asking here?

Thanks,
Bert 

> -----Original Message-----
> From: Presuhn, Randy [mailto:Randy_Presuhn@bmc.com]
> Sent: donderdag 9 januari 2003 23:51
> To: Mreview (E-mail)
> Subject: RE: docsis subscriber mib
> 
> 
> Hi -
> 
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: Thursday, January 09, 2003 13:47
> > To: Mreview (E-mail)
> > Subject: Re: docsis subscriber mib
> > 
> > 
> > This is what I get back (or what I see in terms of discussion
> > on their ipcdn mailing list).
> ...
> 
> Elaborating on my earlier comment:
> 
> If the purpose of adding an additional time stamp object is
> to support detection of the cases Dave Perkins outlined,
> wouldn't it be simpler to replace the TruthValue with a
> TestAndIncr?  This would get rid of the odd read/write
> semantics, prevent the worst replay scenarios, and allow
> recovery in the "lost response" case.
> 
> The semantics they're proposing for these objects really
> don't match up with TruthValue.
> 
>  ------------------------------------------------------
>  Randy Presuhn          BMC Software, Inc.  1-3141
>  randy_presuhn@bmc.com  2141 North First Street
>  Tel: +1 408 546-1006   San José, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------
>