Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)
RFC 5098
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)
(Tim Polk)
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...