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

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 16 Aug 2004 11:38:46 -0600

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 

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 16 Aug 2004 11:18:15 -0700

Hi -

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 16 Aug 2004 11:55:12 -0700

Hi -

> From: "Randy Presuhn" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, August 16, 2004 11:18 AM
> Subject: Re: [ipcdn] comments on draft-ietf-ipcdn-pktc-signaling-05.txt(part 4)
...
...

But we can't do this due to an oversight in the way conformance
material works, since the object is technically not-accessible.  :-(

Anyway, I'm content that you've thought through the implications of
the constraint.

Randy