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

Hi -

> From: Jean-Francois Mule <[email protected]>
> Sent: Aug 3, 2004 2:32 PM
> To: Randy Presuhn <[email protected]>, [email protected]
> Subject: RE: [ipcdn] comments on draft-ietf-ipcdn-pktc-signaling-05.txt (part	4)
...
> > 14) pktcSigDevCodecComboIndex: where does the range
> > constraint (1..255) come from?  There's nothing in the 
> > document to justify that particular upper bound.
> 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).

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.

> > 16) pktcSigDev*Cadence:   wouldn't it be simpler to put these
> > ten objects into a table?  just a thought....
>
> What if we only need one row?

As it's currently written, all of these objects are mandatory,
so I don't see how one could have only one row.

> > 18) pktcSignalingIndex: where does the range constraint
> > (1..255) come from? There's nothing in the document to
> > justify that particular upper bound.
> It is a reasonable limit.
...

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.

Randy