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

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

(Dan Romascanu; former steering group member) Yes

Yes (2007-10-18)
No email
send info
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 steering group member) No Objection

No Objection ()
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ()
No email
send info

(David Ward; former steering group member) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ()
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ()
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ()
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ()
No email
send info

(Mark Townsley; former steering group member) No Objection

No Objection ()
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ()
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ()
No email
send info

(Sam Hartman; former steering group member) No Objection

No Objection ()
No email
send info

(Tim Polk; former steering group member) No Objection

No Objection (2007-10-15)
No email
send info
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...