Subject: RE: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 6 Jul 2005 17:25:51 -0400

Randy,

The comments in your six emails (below is the first one I received) look
very reasonable.

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?

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.

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.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randy Presuhn
Sent: Saturday, June 25, 2005 1:15 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09

Hi Rich -

> From: "Woundy, Richard" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Sent: Friday, June 24, 2005 11:51 AM
> Subject: RE: [ipcdn] Cable Device MIB, Draft 09 released
>
> Thanks! I attached the XML version, which might help slightly.
...

I tried Bill Fenner's tool on it, and got quite a few diagnostics.
Background by Bill:
   Another tool that is worth running on the xml source before using
   xml2rfc on it is at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ ;
   it will check that the source is well-formed and valid according to
   the DTD (XML generated outside of a validating editor is often not
   valid, and sometimes even not well-formed, even though xml2rfc
creates
   a fine-looking document from it), and also checks for various other
   errors including the IPR requested.

The warnings are mostly due to inappropriate characters (like spaces or
periods) in things like xref targets and anchors. Clear those up, and
you'll know whether the complaints about unreferenced references are
real.  These aren't terribly critical, as far as I'm concerned, but it's
probably good housekeeping to take care of them now, since it would be
one less potential source of error during final RFC editing.

The messages I received were:

Validation results for C:\My
Documents\draft-ietf-ipcdn-device-mibv2-09.xml
Processing...

Validating document...
193: element xref: validity error : Syntax of value for attribute target
of xref is not valid
 192: "Data-Over-Cable Service Interface Specification".  A term
referring to the
 193: ITU-T J.112 <xref target="ITU-T J.112" />
 194: Annex B standard for cable modem systems. <xref target="RFI1.0" />

212: element section: validity error : Syntax of value for attribute
anchor of section is not valid
 211:
 212: <section anchor="mac packet" title="Media Access Control (MAC)
Packet">
 213: <t>

4061: element reference: validity error : Syntax of value for attribute
anchor of reference is not valid
4060:
4061:  <reference anchor="ITU-T J.112"
target="http://www.itu.int/ITU-T/studygroups/com09/">
4062:   <front>

...validation failed
Performing additional checks...
142: fyi: anchor framework not referenced
 141:
 142: <section anchor="framework" title="The Internet-Standard
Management Framework">
 143: <t>

159: fyi: anchor glossary not referenced
 158:
 159: <section anchor="glossary" title="Glossary">
 160: <t>

165: fyi: anchor catv not referenced
 164: </t>
 165: <section anchor="catv" title="CATV">
 166: <t>

173: fyi: anchor cm not referenced
 172:
 173: <section anchor="cm" title="CM or Cable Modem">
 174: <t>

180: fyi: anchor cmts not referenced
 179:
 180: <section anchor="cmts" title="CMTS or Cable Modem Termination
System">
 181: <t>

190: fyi: anchor docsis not referenced
 189:
 190: <section anchor="docsis" title="DOCSIS or Data-Over-Cable Service
Interface Specification">
 191: <t>

199: fyi: anchor downstream not referenced
 198:
 199: <section anchor="downstream" title="Downstream">
 200: <t>

205: fyi: anchor head-end not referenced
 204:
 205: <section anchor="head-end" title="Head-end">
 206: <t>

212: fyi: anchor mac packet not referenced
 211:
 212: <section anchor="mac packet" title="Media Access Control (MAC)
Packet">
 213: <t>

218: fyi: anchor rf not referenced
 217:
 218: <section anchor="rf" title="RF">
 219: <t>

224: fyi: anchor snmp not referenced
 223:
 224: <section anchor="snmp" title="Simple Network Management Protocol
(SNMP)">
 225: <t>

232: fyi: anchor upstream not referenced
 231:
 232: <section anchor="upstream" title="Upstream">
 233: <t>

240: fyi: anchor introduction not referenced
 239:
 240: <section anchor="introduction" title="Introduction">
 241: <t>

263: fyi: anchor mibstructure not referenced
 262:
 263: <section anchor="mibstructure" title="Structure of the MIB">
 264: <t>

308: fyi: anchor ipv4 not referenced
 307:
 308: <section anchor="ipv4" title="IPv4 Compliance">
 309: <t>

321: fyi: anchor management not referenced
 320:
 321: <section anchor="management" title="Management requirements">
 322:

323: fyi: anchor upgrades not referenced
 322:
 323: <section anchor="upgrades" title="Handling of Software upgrades">
 324: <t>

366: fyi: anchor events not referenced
 365:
 366: <section anchor="events" title="Events and Notifications">
 367: <t>

380: fyi: anchor throttling not referenced
 379:
 380: <section anchor="throttling" title="Notification Throttling">
 381: <t>

388: fyi: anchor ratethrottling not referenced
 387:
 388: <section anchor="ratethrottling" title="Notification rate
throttling">
 389: <t>

409: fyi: anchor limitingrate not referenced
 408:
 409: <section anchor="limitingrate" title="Limiting the notification
rate">
 410: <t>

430: fyi: anchor protocolfilters not referenced
 429:
 430: <section anchor="protocolfilters" title="Protocol Filters">
 431: <t>

451: error: <figure> inside <t> is deprecated by rfc2629bis
 450: filters.
 451: <figure anchor="filterfigure">
 452: <artwork>

491: fyi: anchor inboundllcfilters not referenced
 490:
 491: <section anchor="inboundllcfilters" title="Inbound LLC Filters -
docsDevFilterLLCTable">
 492: <t>

506: fyi: anchor specialfilters not referenced
 505:
 506: <section anchor="specialfilters" title="Special Filters">
 507: <t>

513: fyi: anchor spoofingfilters not referenced
 512:
 513: <section anchor="spoofingfilters" title="IP Spoofing Filters -
docsDevCpeTable, docsDevCpeInetTable">
 514: <t>

540: fyi: anchor snmpfilters not referenced
 539:
 540: <section anchor="snmpfilters" title="SNMP Access Filters -
docsDevNmAccessTable">
 541: <t>

559: fyi: anchor ipfilters not referenced
 558:
 559: <section anchor="ipfilters" title="IP Filtering -
docsDevFilterIpTable">
 560: <t>

609: fyi: anchor outboundllcfilters not referenced
 608:
 609: <section anchor="outboundllcfilters" title="Outbound LLC Filters">
 610: <t>

624: fyi: anchor definitions not referenced
 623:
 624: <section anchor="definitions" title="Definitions">
 625: <t>

626: error: <figure> inside <t> is deprecated by rfc2629bis
 625: <t>
 626: <figure>
 627: <artwork><![CDATA[

3776: fyi: anchor acknowledgments not referenced
3775:
3776: <section anchor="acknowledgments" title="Acknowledgments">
3777: <t>

3790: fyi: anchor revisions not referenced
3789:
3790: <section anchor="revisions" title="Revision Descriptions">
3791: <t>

3829: fyi: anchor securityconsiderations not referenced
3828:
3829: <section anchor="securityconsiderations" title="Security
Considerations">
3830: <t>

3: warning: anchor RFC2863 not referenced
   2: <?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
   3: <?rfc toc="yes" ?>
   4: <?rfc symrefs="yes" ?>

3: fyi: anchor RFC3014 referred to in plain text as [RFC3014]
   2: <?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
   3: <?rfc toc="yes" ?>
   4: <?rfc symrefs="yes" ?>

3: warning: anchor RFC3411 not referenced
   2: <?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
   3: <?rfc toc="yes" ?>
   4: <?rfc symrefs="yes" ?>

3: fyi: anchor RFC3413 referred to in plain text as [RFC3413]
   2: <?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
   3: <?rfc toc="yes" ?>
   4: <?rfc symrefs="yes" ?>

3: warning: anchor RFC3617 not referenced
   2: <?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
   3: <?rfc toc="yes" ?>
   4: <?rfc symrefs="yes" ?>

4084: warning: anchor OSSI1.1 not referenced
4083:
4084:  <reference anchor="OSSI1.1"
target="http://www.cablemodem.com/specifications/">
4085:   <front>

4095: warning: anchor OSSI2.0 not referenced
4094:
4095:  <reference anchor="OSSI2.0"
target="http://www.cablemodem.com/specifications/">
4096:   <front>

...done

Randy

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 6 Jul 2005 14:57:14 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>; "Marez Kevin-MGI1375" <[email-masked]>
> Cc: <[email-masked]>
> 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

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.

> this in an offline discussion?

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

> support for some of these deprecated groups, and this draft should

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.

...

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