RE: comments on draft-ietf-ipcdn-pktc-signaling-05.txt(part 4)

Hi Randy,

   I had a call with Gordon Beacham the editor this morning and this one thread came up...
   You wrote:
> > > 14) pktcSigDevCodecComboIndex: where does the range constraint 
> > > (1..255) come from?  There's nothing in the document to 
> > > justify that particular upper bound.

   I wrote:
> > There is a hardware implication on how many number of 
> > vo-codecs an MTA should be capable of supporting. 
> > In the packetcable codec spec, we 
> > provide some guidance but we think that 255 is much more 
> > than what we need (beyond that, the cost of memory 
> > on the MTA is most likely going to outweight the 
> > benefits).

   You answered: 
> We should be very careful when introducing limits that aren't 
> required by protocol or architecture, particularly for 
> read-only information like this. The limit provides no 
> benefits to implementations, and represents a risk with 
> respect to future innovations.

  You also wrote w.r.t. pktcSignalingIndex
> What harm would come from an implementation supporting a 
> larger value? If there is none, then I'd argue that that 
> specific upper bound isn't justified by protocol or architecture.

Reading through your responses, I agree in general with not putting constraints that are not justified when doing architecture design. Behind the mib agent and the pure mib object definition, there is real code running and we have found that implementers want us (CableLabs) to help them make those choices and add constraints or reasonable limits. They want those constraints so that they can safely software QA the code within those reasonable limits.

255 is a very reasonable limit for the devices that will implement this spec for the many years to come imho. So, is your argument purely academic or is it based on serious limitations for the future - which I do not see? Is it a showstopper if we stick with 255?

  Thanks,
Jean-François