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

From: Randy Presuhn <[email-masked]>
Date: Tue, 3 Aug 2004 13:58:37 -0700 (GMT-07:00)

Hi -

More comments on draft-ietf-ipcdn-pktc-signaling-05.txt
based on draft-ietf-ops-mib-review-guidelines-03.txt

14) pktcSigDevCodecComboIndex: where does the range
constraint (1..255) come from?  There's nothing in the document
to justify that particular upper bound.

15) pktcSigDevCallerIdSigProtocol: the DESCRIPTION needs to
spell out what is meant by each enumeration

16) pktcSigDev*Cadence:   wouldn't it be simpler to put these
ten objects into a table?  just a thought....

17) pktcSigDefMediaStreamDscp: There's no antecedant for
"the new connection".  Is "new connections" intended?

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

19) pktcSigDefNcsReceiveUdpPort: where does the lower range
constraint come from?

20) pktcSigPowerRingFrequency: for each of the enumeration values,
the DESCRIPTION clause should spell out what that value means.

21) pktcSigPulseSignalType: should spell out what each enumeration
value means in the DESCRIPTION.

22) pktcSigPulseSignalFrequency: does the "must" mean "MUST"
in the sense that an attempt to write a value incompatible with
the instance's pktcSigPulseSignalType must be rejected?  What value
does it take / can it be set to for "inapplicable" signal types?

23) pktcSigPulseSignalDbLevel: What value does it take / can it be
set to for inapplicable signal types?  

24) pktcSigPulseSignalDuration: what happens when something attempts
to set this to a value that doesn't fall on one of the increment boundaries,
or on the wrong increment boundary for the specific signal type?

25) pktcSigPulseSignalPulseInterval: same questions.

26) pktcSigPulseSignalRepeatCount: "must" means "MUST", right?
Same questions as (24) and (25).

27) pktcSigDevCIDFskAfterRing: how does one know whether a system
is "international" or not?  Is the table supposed to be of defaults?
When "not used", what happens when one tries to get/set this object?

28) pktcSigDevCIDFskAfterDTAS: same questions as (27)

29) pktcSigDevCIDFskAfterRPAS: same questions as (27)
For example, what happens when a system is not international
but the pktcSigDevCIDMode is rpAsETS?

30) pktcSigDevCIDRingAfterFSK: same as (27)

***more to come***

Randy

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

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 3 Aug 2004 15:32:00 -0600

Some opinions inline.
Jean-François 

Randy wrote:
> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Tuesday, August 03, 2004 2:59 PM
> To: [email-masked]
> Subject: [ipcdn] comments on 
> draft-ietf-ipcdn-pktc-signaling-05.txt (part 4)
> 
> 
> Hi -
> 
> 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).
 
> ten objects into a table?  just a thought....
What if we only need one row?

> justify that particular upper bound.
It is a reasonable limit.

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 3 Aug 2004 15:00:13 -0700 (GMT-07:00)

Hi -

> From: Jean-Francois Mule <[email-masked]>
> Sent: Aug 3, 2004 2:32 PM
> To: Randy Presuhn <[email-masked]>, [email-masked]
> Subject: RE: [ipcdn] comments on draft-ietf-ipcdn-pktc-signaling-05.txt (part	4)
...
> 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.

> 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.

> 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