Skip to main content

Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)
draft-ietf-ipcdn-pktc-signaling-15

Yes


No Objection

(Chris Newman)
(Cullen Jennings)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Sam Hartman)

Note: This ballot was opened for revision 15 and is now closed.

Dan Romascanu Former IESG member
Yes
Yes (2007-10-18) Unknown
1) Expand MGCP at first occurence in Section 3.3

2) Section 4: s/ where each index (ifIndex) refers to a unique enpoint/ where each index(ifIndex) value refers to a unique enpoint

3) Section 4.2 - the terminology 'international object' and 'international table' is not clear. I suggest to replace it with an explanation that this is about international IP telephony features

4) There are many instances of read-write and read-create objects where the text 'The value of this MIB Object MUST NOT persist accross MTA reboots'. I believe that the intention is that at reboot the objects would return to the default values where available. If this is the case I would suggest to include some text on this respect at the begining of the MIB module to make the desired procedure more clear for agents implementers. 

5) REFERENCE clause of pktcSigDefNcsReceiveUdpPort - use full name of the PacketCable specification

6) The text in the REFERENCE clause of pktcSigPowerRingFrequency seems to better belong to the DESCRIPTION clause

7) Many REFERENCE clauses in the specification just provide the name of the specification (from ETSI for example). It would be useful if section or table numbers were provided. 

6)
Chris Newman Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection (2007-10-15) Unknown
The security considerations call out the sensitivity of only one readable object, the
pktcSigEndPntStatusCallIpAddress, as valuable to would-be attackers.  

I wondered if two others might merit an explicit mention:

  Wouldn't the information in pktcSigDevCodecMax be sueful when launching a denial
     of service attack?
  It also seems like pktcSigEndPntStaatus Error could be helpful in some attacks...