Re: Problems in XML source of Cable Device MIB, Draft 09

Hi -

> From: "Woundy, Richard" <Richard_Woundy <at> cable.comcast.com>
> To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>; "Marez Kevin-MGI1375" <Kevin.Marez <at> motorola.com>
> Cc: <ipcdn <at> ietf.org>
> Sent: Wednesday, July 06, 2005 2:25 PM
> Subject: RE: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09
...
> The comments in your six emails (below is the first one I received) look
> very reasonable.

Thanks.    Keep in mind that these are really just commentary on the
diagnostics generated by tools.  I still need to plow through the document
"manually" for the stuff that programs don't catch (yet).  Those are the
comments that are more likely to need discussion.

> I would like to post a revised draft that addresses all of your comments
> before the July 18th cut-off. Kevin, can we talk about how we would do
> this in an offline discussion?

Fine with me, just keep in mind my comment above.

> I think the WG needs to discuss which deprecated groups should be
> included in the docsDevCmCompliance and docsDevCmtsCompliance statement
> (if any). In my opinion, some (if not all) of the deprecated groups need
> to be implemented on CMs and CMTSs for backwards compatibility with
> various cable OSS systems... but maybe cable operators are ready to drop
> support for some of these deprecated groups, and this draft should
> reflect that.

As long as the WG is able to agree on what it wants to say, we can make
sure the MIB module conformance material reflects that intent.

> I have oonly a few minor reactions to your other comments, that I will
> address over the next few days. For example, with respect to
> docsDevNmAccessTable, according to DOCSIS a cable modem may boot in a
> mode where SNMP Coexistence mode is disabled, but the same cable modem
> may boot in a mode where SNMP Coexistance mode or SNMPv3 management is
> enabled, depending on the boot parameters received.
...

Understood.  Two points I'll offer in reply:
1)  A more common way of modeling this kind of a situation in a MIB module
would for the tables to always be available, independent of the "mode" in use
at the moment, with a separate object indicating the current mode.  However,
I recognize that changing this aspect of this MIB module does not seem to
make sense at this stage.
2) As this draft's own security considerations section states, "deployment of
SNMP versions prior to SNMPv3 is NOT RECOMMENDED".

Randy