Last Modified: 2005-06-27
Done | Post final I-D on Baseline Privacy MIB; Last call | |
Done | Post I-Ds revising RF and CM MIBs to support DOCSIS1.1 and for compliance with SNMPv3 and IPv6 | |
Done | Submit Baseline Privacy MIB to IESG for publication as a Standards Track RFC | |
Done | Submit DOCSIS Subscriber Management MIB to IESG for consideration as a Standards Track RFC | |
Done | Submit DOCSIS 1.1 QoS MIB to IESG for consideration as a Standards Track RFC | |
Done | Submit DOCSIS BPI+ MIB to IESG for consideration as a Standards Track RFC | |
Sep 04 | Submit updated DOCSIS RF MIB to IESG for consideration as a Standards Track RFC (Proposed Standard) | |
Sep 04 | Submit updated DOCSIS Cable Device MIB to IESG for consideration as a Standards Track RFC | |
Sep 04 | Submit DOCSIS Event Notification MIB to IESG for consideration as a Standards Track RFC | |
Sep 04 | Submit PacketCable/IPCableCom MTA device MIB to IESG for consideration as a Standards Track RFC | |
Sep 04 | Submit PacketCable/IPCableCom MTA signaling MIB to IESG for consideration as a Standards Track RFC | |
Sep 04 | Submit PacketCable/IPCableCom MTA event MIB to IESG for consideration as a Standards Track RFC | |
Dec 04 | Submit Cablehome MIB for managing residential gateway or home router device to IESG for consideration as Standards Track RFC | |
Dec 04 | Submit Cablehome MIB for MIB for managing private address-to-public address mappings for a residential gateway or home router device to IESG for consideration as Standards Track RFC | |
Dec 04 | Submit Cablehome MIB for managing the address lease acquistion client and the address lease server functionality of a residential gateway or home router device to IESG for consideration as Standards Track RFC | |
Dec 04 | Submit Cablehome MIB for managing diagnostic utilities used to remotely test the connectivity between a residential gateway and privately-addressed LAN hosts to IESG for consideration as Standards Track RFC | |
Dec 04 | Submit Cablehome MIB for managing firewall attributes,monitoring firewall attacks, and managing security certificates in a residential gateway or home router device to IESG for consideration as Standards Track RFC | |
Jan 05 | Revaluate charter and milestones or conclude wg |
RFC | Status | Title |
---|---|---|
RFC2669 | PS | Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems |
RFC2670 | PS | Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces |
RFC3083 | I | Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems |
RFC4036 | Standard | Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management |
IETF IPCDN Meeting Notes IETF#63, IP over Cable Data Networks WG Paris, France Monday, August 1, 2005 Reported and edited by Jean-Francois Mule' (jfm@cablelabs.com) --- WG Meeting Summary --- ------------------ About ten IETF participants attended the IPCDN WG meeting at IETF #63 in Paris on August 1st 2005. Total meeting time was one hour. There were no meeting materials prepared for this meeting as the goal was to use the time as a working session to resolve known issues on the main active drafts. The meeting essentially focused on the cable device MIB v2 and the top 4 remaining issues. The action items (AI) are outlined and called out in the text below. 1/ Agenda Bashing A jabber session was also initiated and Rich Woundy, ipcdn co-chair participated remotely. The jabber chat room is: ipcdn@conference.ietf.jabber.com. The proposed agenda was accepted by the wg without modifications, it is also available at: http://www.ipcdn.org/meetings.html and as part of the IETF proceedings. 2/ Administration We briefly discussed the re-chartering & milestone updates. Below is the newly proposed date corresponding to the "wg done" milestone. o DOCSIS Cable Device MIB version 2: Oct 2005 o RF MIB v2: Oct 2005 o MTA MIB: Oct 2005 o Signaling MIB: Oct 2005 o Management Event MIB: Dec 2005It was commented that those dates look aggressive for some of the work items so co-authors should review the above. # Action Item (AI): # Upon review of notes by wg, if there is no comments on the above # milestones, Jean-Francois to send updated charter proposal to Bert # for approval. # Due by end of August 2005 3/ IPCDN DOCSIS mibs 3.1/ DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-09.txt Editors: Kevin Marez & Rich Woundy http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt We spent most of the meeting reviewing the 4 top remaining issues, see summary sent by Rich and Kevin in: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html + ISSUE #1: DEFVAL for docsDevNmAccessInterfaces Raised by Randy, the issue is, in the defval we have a 4 octet value => How can systems with interfaces in a number not multiple of 8 interpret the DEFVAL value. Are bits ignored? Randy commented that he would be ok if there was some mention like 'octets containing bits corresponding to non-existent interfaces are ignored.' That said, if there are implementations that would reject a SET, then we need to say something about that. Rich commented that the DEFVAL was added due to prior MIB doctor comment and that the object is now deprecated. Bert asked whether there was any concern deleting the DEFVAL. Proposal for wg review:
-- Also, we should change the DESCRIPTION of docsDevCpeStatus -- and docsDevCpeInetRowStatus to document how the agent adds rows. See issue raised by Randy and the email summary provided by Rich for the context around this issue #2. We had some discussions around the persistency of those tables, the fact that the CM config file drives the row creation at boot-up and the fact that they are read-create tables so admins can also create entries as Bert pointed out. In most cases (except for docsDevEvControlTable), entries do not persist across CM reboots. Even in the case of docsDevEvControlTable, after some discussion, we believe that the entries are cleared and "recreated" after the CM reads the config file. That is the common understanding. Bert said: add a statement ("this is a deprecated table, this is vendor specific as to what vendors do with this table, mgmt app cannot expect a certain behavior"). + ISSUE #3: docsDevEvReporting and local(0) rows Comment close: ID authors agree with Randy's comment re: local(0) rows MUST persist. Text will be revised. in docsDevFilterLLCTable: Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated. Proposal: DELETE above text if nobody complains after reading the meeting notes + ISSUE #4: docsDevFilterLLCTable Issue is around text for the level of requirements on table persistence. Agree with Rich's text proposal: |"Table entries MUST NOT persist across reboots for cable modems." Rich also proposed to apply this requirement to: NmAccess, FilterLLC, FilterIp, Policy, Tos, Cpe and InetCpe tables. It was suggested to use SHOULD NOT rather than MUST NOT but other than that, proposal is ok. + Other items on CD Device MIB: Randy added for consideration: wherever we have this "must not persist" langage in table definitions, it would be a plus to indicate that they may come back as entries may reappear when CM reboots and comes up with config file. Or consider adding this in the front paper as a consideration for users of the MIBs if that is too many little edits in the MIB objects. Proposal: add a note on persistence model explaining the persistance of some mib objects and the CM re-creating them upon config file reloading. A comment was made that in general, we should indicate the persistency model in each object rather than in the compliance section. Bert also commented on the compliance sections: if different requirements apply to CM and CMTS, suggestion is to make 2 different compliances. Rich added that the new compliance statement is designed like that. # AI: [authors: Kevin Marez & Rich Woundy] # Authors to summarize list of agreed changed and the technical # changes in the text per wg consensus and issue new draft after AD # review comments are in. # Due by early September? # AD review by Bert due by August 15 3.2/ RF MIB v2 draft-ietf-ipcdn-docs-rfmibv2-13.txt Editor: Eduardo Cardona http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-13.txt Not discussed due to time limit. # AD review by Bert due by August 15 3.3/ IPCablecom/PacketCable MTA MIB draft-ietf-ipcdn-pktc-mtamib-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.txt Not discussed due to time limit. # AD review by Bert due by August 15 3.4/ Signaling MIB draft-ietf-ipcdn-pktc-signaling-08.txt http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.txt Not discussed due to time limit. # AI: authors to close one open issue on tone table by August 20. # Ask Randy to review final proposal. 3.5/ Management Event MIB draft-ietf-ipcdn-pktc-eventmess-04.txt Not discussed due to time limit. # AI: chair (Jean-Francois) to ping authors to understand the status # of the document and define next steps accordingly. http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-04.txt 4/ IPCDN WG next steps Beyond the action items noted above and implementation of the various decisions the wg agreed to, the following is our work plan:
PacketCable/IPCablecom MTA MIB PacketCable/IPCablecom Signaling MIB and request publication by October 2005 |