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

Hi -

> From: "Jean-Francois Mule" <[email protected]>
> To: "Randy Presuhn" <[email protected]>; <[email protected]>
> Sent: Monday, August 16, 2004 10:38 AM
> Subject: RE: [ipcdn] comments on draft-ietf-ipcdn-pktc-signaling-05.txt(part 4)
...
>  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?

It's just been my experience that "very reasonable" limits have a nasty
way of coming back to haunt us.  A read-only table like this is a particularly
suspect, since it limits what device vendors are allowed to support.
The limit doesn't simplify anything on the side of a management application,
since code there will still need to check for out-of-bounds and wrong-type
index values.

An approach that would make me happier while still meeting your
stated goals would be to specify pktcSignalingIndex with a SYNTAX
of Unsigned32(1..4294967295), and then use a SYNTAX clause in
the OBJECT clause in the MODULE part of the conformance material
(see RFC 2580 5.4.3.1) to give the required-to-implement range,
but this is only a suggestion.

> Is it a showstopper if we stick with 255?
...

No.  I just wanted to be sure the group is aware of the implication of
what's there, i.e., that it prohibits vendors from supporting more than
255 entries.  If someone ever needed to support more, they'd need to
define a new table.  If this is as improbable as you're saying, then it's
a non-issue.

Randy