Skip to main content

Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management
RFC 4036

Revision differences

Document history

Date Rev. By Action
2015-10-14
16 (System) Notify list changed from ,  to (None)
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for Allison Mankin
2005-05-03
16 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-05-03
16 Amy Vezza [Note]: 'RFC 4036' added by Amy Vezza
2005-04-15
16 (System) RFC published
2004-11-05
16 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-11-04
16 Amy Vezza IESG state changed to Approved-announcement sent
2004-11-04
16 Amy Vezza IESG has approved the document
2004-11-04
16 Amy Vezza Closed "Approve" ballot
2004-11-04
16 Bert Wijnen Status date has been changed to 2004-11-24 from 2004-10-21
2004-11-04
16 Bert Wijnen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bert Wijnen
2004-10-21
16 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin
2004-10-21
16 Bert Wijnen Checking with otehr ADs if they are now happy with this revision
2004-10-21
16 Bert Wijnen Status date has been changed to 2004-10-21 from 2004-09-28
2004-10-12
16 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-10-12
16 (System) New version available: draft-ietf-ipcdn-subscriber-mib-16.txt
2004-09-28
16 Bert Wijnen State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Bert Wijnen
2004-09-28
16 Bert Wijnen As agreed with author and WG chairs, new revision is expected to address editorial changes and ifx one DISCUSS
2004-09-28
16 Bert Wijnen Status date has been changed to 2004-09-28 from 2004-09-20
2004-09-28
16 (System) Removed from agenda for telechat - 2004-09-27
2004-09-27
16 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2004-09-27
16 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten
2004-09-27
16 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-09-27
16 Harald Alvestrand
[Ballot comment]
Reviewed by John Loughney, Gen-ART

His review:

Document seems ready, a couple of small nits:

1) Shouldn't the Security Considerations come before the …
[Ballot comment]
Reviewed by John Loughney, Gen-ART

His review:

Document seems ready, a couple of small nits:

1) Shouldn't the Security Considerations come before the references?
2) For the references, there is text that says the following:

        ************************************************************
        * NOTES TO RFC Editor (to be removed prior to publication) *
        *                                                          *
        *    The I-D  (or a *
        * successor) is expected to eventually replace RFC 2669.  *
        * If that draft (or a successor) is published as an RFC    *
        * prior to or concurrently with this document, then the    *
        * normative reference [RFC2669] should be updated to      *
        * point to the replacement RFC, and the reference tag      *
        * [RFC2669] should be updated to match.                    *
        *                                                          *
        ************************************************************

Shouldn't the I-D just be referenced? Some of these references
seem that they should reference the I-D, not the RFC.
2004-09-27
16 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2004-09-27
16 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2004-09-27
16 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2004-09-26
16 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-09-26
16 Allison Mankin
[Ballot discuss]
The document states:
  Effective network filtering of TCP traffic requires that implementors
  MUST follow the recommendations in section 3.2.6.
But there …
[Ballot discuss]
The document states:
  Effective network filtering of TCP traffic requires that implementors
  MUST follow the recommendations in section 3.2.6.
But there is no section 3.2.6 here.  MUST must be clear.
2004-09-26
16 Allison Mankin [Ballot Position Update] New position, Discuss, has been recorded for Allison Mankin by Allison Mankin
2004-09-24
16 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2004-09-24
16 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie
2004-09-24
16 Ted Hardie
[Ballot comment]
I have to say that I think the v4-only nature of this doc is pretty questionable; I understand
that the document is relative …
[Ballot comment]
I have to say that I think the v4-only nature of this doc is pretty questionable; I understand
that the document is relative to DOCSIS deployments which don't deploy v6, but this
is starting them down a design road that is going to require more than a little backtracking.
The whole mechanism presumes that use of multiple address is a wrong/restricted
activity; this isn't the right focus for v6.  Rather than working out some management
framework than can handle both, they could end up with such separate things that
the user experience is affected by the overlapping attempts at control (or the
attempts to control are frustrated trivially).

I'm not DISCUSSing this document, since it is clear on its scope, but I strongly encourage
them to create a joint v4/v6 management scope as a successor to this, rather than
a v6 auxillary to this.
2004-09-24
16 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2004-09-24
16 Steven Bellovin [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin
2004-09-22
16 Russ Housley
[Ballot comment]
The 2nd paragraph of Section 9 says:
  :
  : Effective network filtering of TCP traffic requires that implementors
  : MUST …
[Ballot comment]
The 2nd paragraph of Section 9 says:
  :
  : Effective network filtering of TCP traffic requires that implementors
  : MUST follow the recommendations in section 3.2.6.
  :
  I suggest replacement text:
 
    For network filtering of TCP traffic to be effective, implementors
    MUST follow the recommendations in section 3.2.6.
2004-09-22
16 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2004-09-21
16 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-09-20
16 Bert Wijnen Placed on agenda for telechat - 2004-09-27 by Bert Wijnen
2004-09-20
16 Bert Wijnen Status date has been changed to 2004-09-20 from 2004-09-19
2004-09-20
16 Bert Wijnen State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Bert Wijnen
2004-09-20
16 Bert Wijnen Note field has been cleared by Bert Wijnen
2004-09-20
16 Bert Wijnen [Ballot Position Update] New position, Yes, has been recorded for Bert Wijnen
2004-09-20
16 Bert Wijnen Ballot has been issued by Bert Wijnen
2004-09-20
16 Bert Wijnen Created "Approve" ballot
2004-09-20
16 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-09-20
15 (System) New version available: draft-ietf-ipcdn-subscriber-mib-15.txt
2004-09-19
16 Bert Wijnen [Note]: 'IESG... Pls review revision 15.
It has been submitted to the repository on Sunday 19 Sept.' added by Bert Wijnen
2004-09-19
16 Bert Wijnen Status date has been changed to 2004-09-19 from 2004-09-03
2004-09-03
16 Bert Wijnen State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Bert Wijnen
2004-09-03
16 Bert Wijnen
Checking with WG chairs and author(s) when to expect revision to address the IETF Last Call comments (raised by AD right start of IETF Last …
Checking with WG chairs and author(s) when to expect revision to address the IETF Last Call comments (raised by AD right start of IETF Last Call).

I need the new revision by Wed Sept 8th in order to be able to put this on
sept 16th IESG telechat.
2004-09-03
16 Bert Wijnen Status date has been changed to 2004-09-03 from 2004-07-14
2004-08-06
16 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2004-07-16
16 Michelle Cotton IANA Last Call Comments:
Upon approval of this document, the IANA will assign
a mib-2 number to the DOCS-IETF-SUBMGT-MIB.
2004-07-15
16 Amy Vezza Last call sent
2004-07-15
16 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2004-07-15
16 Bert Wijnen State Changes to Last Call Requested from AD Evaluation by Bert Wijnen
2004-07-15
16 Bert Wijnen Last Call was requested by Bert Wijnen
2004-07-15
16 (System) Ballot writeup text was added
2004-07-15
16 (System) Last call text was added
2004-07-15
16 (System) Ballot approval text was added
2004-07-14
16 Bert Wijnen
AD review of revision 14

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: woensdag 14 juli 2004 16:14
To: wsawyer@ieee.org; sawyerwd@comcast.net; Ipcdn (E-mail)
Cc: …
AD review of revision 14

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: woensdag 14 juli 2004 16:14
To: wsawyer@ieee.org; sawyerwd@comcast.net; Ipcdn (E-mail)
Cc: Harrie Hazewinkel
Subject: AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt


Wilson (and WG). Sorry that it took long (again) to do another
good check of this MIB document.

I think this doc is basically OK now. I did find some small things
as per below, and it would be good to fix those at some point.
I propose that I issue an IETF Last Call, and that the below comments
are considered as the initial comments on such an IETF Last Call
and that you address them (or answer them) as part of any other comments
that may come up from IETF Last Call.

Wilson/WG-chair(s), pls let me know if that sounds like a plan or if
you ratehr address/answer the below first.

What I did find is:

From SMICng (strict checking). I thought I had reported this before ( see I
did, but you probably opted to not do it since it is not mandatory).
Oh well, I am including it anayway (again), because I really belive it
is betetr to include them.

  E: f(ipcdnsub.mi2), (478,15) Item "diffServMIBDataPathGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (479,15) Item "diffServMIBClfrGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (480,15) Item "diffServMIBClfrElementGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (481,15) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (482,15) Item "diffServMIBActionGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (483,15) Item "diffServMIBAlgDropGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (484,15) Item "diffServMIBCounterGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (487,11) Item "diffServDataPathStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (493,11) Item "diffServClfrStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (499,11) Item "diffServClfrElementStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (506,11) Item "diffServMultiFieldClfrAddrType" should be IMPORTed
  E: f(ipcdnsub.mi2), (512,11) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed
  E: f(ipcdnsub.mi2), (518,11) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed
  E: f(ipcdnsub.mi2), (524,11) Item "diffServAlgDropStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (530,11) Item "diffServDataPathStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (536,11) Item "diffServClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (542,11) Item "diffServClfrElementStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (548,11) Item "diffServMultiFieldClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (554,11) Item "diffServActionStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (560,11) Item "diffServCountActStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (566,11) Item "diffServAlgDropStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (572,11) Item "diffServAlgDropType" should be IMPORTed

According to our MIB review guidelines (draft-ietf-ops-mib-review-guidelines-03.txt)
section 4.4, 3rd para:
  Note that exemptions to this general requirement are granted by RFC
  2580
Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in
  the OBJECT clause of a MODULE-COMPLIANCE statement or in the
  VARIATION clause of an AGENT-CAPABILITIES statement.  Some MIB
  compilers also grant exemptions to descriptors of notifications
  appearing in a VARIATION clause and to descriptors of object groups
  and notification groups referenced by a MANDATORY-GROUPS clause, a
  GROUP clause, or an INCLUDES clause, although RFC 2580 (through
  apparent oversight) does not mention those cases.  The exemptions are
  sometimes seen as unhelpful because they make IMPORTS rules more
  complicated and inter-module dependencies less obvious than they
  otherwise would be.  External symbols referenced by compliance
  statements and capabilities statements MAY therefore be listed in the
  IMPORTS statement;  if this is done, it SHOULD be done consistently.

So it is not mandatory to do the IMPORTs, but in my view it will help in
many places with less warning/errors. So may I suggest to add the IMPORT
statement for the above.

Also, all documents from whihc you IMPORT (implied or explicit) you must
put in normative reference section (which you have done). But all such
references MUST have a citation in the text (see MIB review guidelines,
(draft-ietf-ops-mib-review-guidelines-03.txt, sect 3.5):
  3.5.  References Sections

  Section 4.7f of [RFC2223bis] specifies the requirements for the
  references sections.  In particular, there MUST be separate lists of
  normative and informative references, each in a separate section.
  The style SHOULD follow that of recently published RFCs.

  The standard MIB boilerplate available at
  http://www.ops.ietf.org/mib-boilerplate.html includes lists of
  normative and informative references that MUST appear in all IETF
  specifications that contain MIB modules.  If items from other MIB
  modules appear in an IMPORTS statement in the Definitions section,
  then the specifications containing those MIB modules MUST be included
  in the list of normative references.  When items are imported from an
  IANA-maintained MIB module the corresponding normative reference
  SHALL point to the on-line version of that MIB module.  It is the
  policy of the RFC Editor that all references must be cited in the
  text;  such citations MUST appear in the overview section where
  documents containing imported definitions (other those already
  mentioned in the MIB boilerplate) are required to be mentioned (cf.
  Section 3.2).

You have such a reference for RFC3291 (as required), but no citation
to [RFC3291] anywhere in the document. Can you pls add it at
some point in the text.


I have some other nits/questions:

1. Desription clause of docsSubMgtCpeIpIndex states, towards the end:

      the table and the packet is forwarded.  If the number of entries
      equals the docsSubMgtCpeControlMaxCpeIp, AND
      docsSubMgtCpeControlActive is true, then the packet is dropped.
      Otherwise the packet is forwarded. "

  In the case that the packet is forwarded, will then also an entry be
  created? That is not clear to me. May I suggest to add some text to
  make that 100% clear?

2. In description clause of docsSubMgtCmFilterTable it states:

      Zero is a distinguished value, indicating that the default
      filtering action is to be taken, rather than that associated

  Mmm... a value for the table? I guess you mean that such a zero
  value "in any of the columns of the table has a special maening.
  Right? Might want to make that clearer.

3. I see:
    1.3.6.1.2.1.xx.1.6      docsSubMgtCmFilterTable
    1.3.6.1.2.1.xx.1.6.1    docsSubMgtCmFilterEntry
    1.3.6.1.2.1.xx.1.6.1.1  docsSubMgtSubFilterDownstream
    1.3.6.1.2.1.xx.1.6.1.2  docsSubMgtSubFilterUpstream
    1.3.6.1.2.1.xx.1.6.1.3  docsSubMgtCmFilterDownstream
    1.3.6.1.2.1.xx.1.6.1.4  docsSubMgtCmFilterUpstream
  I think that for naming consistency, it might be better to rename
    1.3.6.1.2.1.xx.1.6.1.1  docsSubMgtSubFilterDownstream
    1.3.6.1.2.1.xx.1.6.1.2  docsSubMgtSubFilterUpstream
  into something like:
    1.3.6.1.2.1.xx.1.6.1.1  docsSubMgtCmSubFilterDownstream
    1.3.6.1.2.1.xx.1.6.1.2  docsSubMgtCMmubFilterUpstream
  so as to make it clearer (from the name/descriptor) that these 2
  objects exists in the docsSubMgtCmFilterTable.

4. I am a bit worried about the hard limit (range) of 1-255 for FilterGroupIndex.
  Is this enough forever in the future? Or would it be wiser to use a larger
  range (and limit via MODULE-COMPLIANCE, as you already do)?
  I see it was larger before, and that you changed it to this smaller range.
  So I guess you are doing this consciously.

5. In description clause of docsSubMgtFilterGroupIndex I see:

      the four. Because this is the only field in this table, it is
      read-only, contrary to the usual SNMP custom of making indices
      not-accessible.

  Probably better to change SNMP into SMI.

6. In the Security Considerations, I think I would change the 2nd para
  to make a positive statement, namely that you MUST follow recommendations
  in sect 2.2.6 in order to deploy an effective filtering.

Thanks,
Bert
2004-07-14
16 Bert Wijnen Status date has been changed to 2004-07-14 from 2004-07-09
2004-07-09
16 Bert Wijnen Checking again with MIB doctor Harrie
2004-07-09
16 Bert Wijnen Status date has been changed to 2004-07-09 from 2004-02-23
2004-05-17
16 Bert Wijnen Harrie Hazewinkel will have another look in the next week or two
2004-02-23
16 Bert Wijnen State Changes to AD Evaluation from AD Evaluation::Revised ID Needed by Bert Wijnen
2004-02-23
16 Bert Wijnen [Note]: 'New revision expected/needed.
Responsible: WG and authors' has been cleared by Bert Wijnen
2004-02-23
16 Bert Wijnen New revision 14 supposedly addresses all comments.
WG chair(s) ask me (AD) for re-processing.
So in AD review again
2004-02-23
16 Bert Wijnen Status date has been changed to 2004-02-23 from 2003-09-22
2004-02-16
14 (System) New version available: draft-ietf-ipcdn-subscriber-mib-14.txt
2003-10-27
13 (System) New version available: draft-ietf-ipcdn-subscriber-mib-13.txt
2003-09-22
16 Bert Wijnen State Changes to AD Evaluation::Revised ID Needed from AD is watching by Bert Wijnen
2003-09-22
16 Bert Wijnen
Received additional MIB Doctor review from Harrie Hazewinkel (whom I had asked for review from Diffserv MIB perspective).

Review comments from Harrie were posted to …
Received additional MIB Doctor review from Harrie Hazewinkel (whom I had asked for review from Diffserv MIB perspective).

Review comments from Harrie were posted to IPCDN mailing list on Sept 15th by AD.
2003-09-22
16 Bert Wijnen Status date has been changed to 2003-09-22 from 2003-09-02
2003-09-02
16 Bert Wijnen
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: dinsdag 2 september 2003 14:39
To: 'Woundy, Richard'; IPCDN WG (E-mail)
Cc: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert)
Subject: …
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: dinsdag 2 september 2003 14:39
To: 'Woundy, Richard'; IPCDN WG (E-mail)
Cc: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert)
Subject: AD Review: draft-ietf-ipcdn-subscriber-mib-12.txt


Too late for Last Call I suspect, but this is what I still find
with SMICng, strict checking:
  E: f(ipcdnsub.mi2), (415,15) Item "diffServMIBDataPathGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (416,15) Item "diffServMIBClfrGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (417,15) Item "diffServMIBClfrElementGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (418,15) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (419,15) Item "diffServMIBActionGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (420,15) Item "diffServMIBAlgDropGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (421,15) Item "diffServMIBCounterGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (424,11) Item "diffServDataPathStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (430,11) Item "diffServClfrStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (437,11) Item "diffServClfrElementStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (443,11) Item "diffServMultiFieldClfrAddrType" should be IMPORTed
  E: f(ipcdnsub.mi2), (449,11) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed
  E: f(ipcdnsub.mi2), (455,11) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed
  E: f(ipcdnsub.mi2), (461,11) Item "diffServAlgDropStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (467,11) Item "diffServDataPathStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (473,11) Item "diffServClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (479,11) Item "diffServClfrElementStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (485,11) Item "diffServMultiFieldClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (492,11) Item "diffServActionStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (498,11) Item "diffServCountActStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (504,11) Item "diffServAlgDropStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (510,11) Item "diffServAlgDropType" should be IMPORTed

The draft-ietf-ops-mib-review-guidelines-02.txt document says about this,
sect 4.4. pages 10 and 11):
  ... snip ...
  otherwise would be.  External symbols referenced by compliance
  statements and capabilities statements MAY therefore be listed in the
  IMPORTS statement;  if this is done, it SHOULD be done consistently.

So it is acceptable the way you have done it, but if you do add them it does
make the above errors go away. I thought we had discussed this before...
but maybe it was some other MIB where I did discuss it.

Additional comments/questions:
- I see that references are made to RFC2669 and 2670.
  But at the same time this WG is working on replacements for those
  RFCs, so they will soon be obsoleted. Is it not better to reference
  the replacement documents?
- For objects that are not in a table, like docsSubMgtCpeMaxIpDefault,
  can you add a few words to the DESCRIPTION clause  to describe what
  the expected persistency behaviour is?
- I see:
  docsSubMgtCpeIpAddr OBJECT-TYPE
      SYNTAX      InetAddress
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The IP address either set from provisioning or learned via
      address gleaning or other forwarding means. See
      docsSubMgtCpeIpIndex for the mechanism."
  According to RFc3291, you MUST specify which InetAddressType opbject
  is used to specify the type. So something aka:
      DESCRIPTION
          "The Internet address either set from provisioning or learned
      via address gleaning or other forwarding means. See
      docsSubMgtCpeIpIndex for the mechanism.

      The type of this address is determined by the value of the
      docsSubMgtCpeIpAddressType object."
- In DESCRIPTION clause of: docsSubMgtCmFilterUpstream
  Change:        zero use default classification)
  Into:          zero (use default classification)
- In DESCRIPTION of: docsSubMgtFilterGroupTable
  s/OIDs/object definitions/
  and is it a collection? There is only an index object
- IN DESCRIPTION of: docsSubMgtFilterGroupIndex
    "Provides an OID to which..
  It defines an object, and the diffServClfrElementSpecific
  can point to an instance in this table (it does use the OID
  that identifies the instance).
  Also w.r.t. to the range of this object...
  Is the entry with index zero the (use default classification)?
  or is it not intended to exist? From teh way I read things now,
  there is no need for value 0 in this index object, so better
  not include it in the range I would say.
- docsSubMgtBasicCompliance
  I am not sure were exactly we were with our discussion to the
  wording that only IPv4 needs to be supported. If the
  current DOCSIS only supports IPv4, then just doing IPv4 in
  MODULE-COMPLIANCE is probably OK. Maybe rename it to
  docsSubMgtBasicIPv4Compliance?  It certainly would be good to
  add something about that, either in the DESCRIPTION clause of
  the module compliance itself, or in the InetAddressType and
  InetAddress DESCRIPTION clauses in the compliance statement.
  Let me also add Juergen Schoenwaelders comment (not sure he posted
  it to this WG list):
    Note that scoped link-local addresses are not captured in
    the compliance statement on devices that potentially can
    connect multiple links if you restrict the SYNTAX to
    { ipv4(1) } or { ipv4(1), ipv6(2) }.
    So people should think twice whether it is not good to
    include ipv4z(3) and ipv6z(4) as well so that proper
    support for link-local addresses is required on devices
    which connect multiple links where conflicts can appear.
- I am a little surprised by the definitions that DiffServTables
  only need nonVolatile support. Seems more difficult than volatile,
  so would you not at least add that?
  I do not believe we have such sort of refinements for StorageType
  in any MIB module yet. Can you explain what your thinking is/was?
- Can you add Mike Heard to the Acknowledgement section? I think
  he has contributed quitea bit in some of these discussions.
- I think you need to add RFC3290 as a NORMATIVE reference.
  You are IMPORTing from that document

Thanks,
Bert
2003-09-02
16 Bert Wijnen Status date has been changed to 2003-09-02 from
2003-09-02
16 Bert Wijnen Shepherding AD has been changed to Bert Wijnen from Thomas Narten
2003-08-04
12 (System) New version available: draft-ietf-ipcdn-subscriber-mib-12.txt
2003-06-23
16 Thomas Narten
Major issues encountered after request to advance. New ID of 2003-05-30 is a response to those concerns. Need to verify that issues have been satisfactorily …
Major issues encountered after request to advance. New ID of 2003-05-30 is a response to those concerns. Need to verify that issues have been satisfactorily addressed.
2003-06-23
16 Thomas Narten State Changes to AD is watching from AD Evaluation by Narten, Thomas
2003-05-29
11 (System) New version available: draft-ietf-ipcdn-subscriber-mib-11.txt
2003-03-04
10 (System) New version available: draft-ietf-ipcdn-subscriber-mib-10.txt
2003-02-18
09 (System) New version available: draft-ietf-ipcdn-subscriber-mib-09.txt
2003-02-17
16 Thomas Narten Bert completes MIB Doctor review and says OK
2003-02-17
16 Thomas Narten State Changes to AD Evaluation  :: AD Followup from AD Evaluation  :: External Party by Narten, Thomas
2003-01-23
08 (System) New version available: draft-ietf-ipcdn-subscriber-mib-08.txt
2002-11-05
07 (System) New version available: draft-ietf-ipcdn-subscriber-mib-07.txt
2002-10-09
16 Thomas Narten State Changes to AD Evaluation from Expert Review by narten
2002-10-09
16 Thomas Narten State Changes to Expert Review  -- External Party from Expert Review by narten
2002-10-01
16 Bert Wijnen Bert Wijnen did send extended MIB DOctor review comments to authors and WG mailing list. Copied INT ADs as well.
2002-10-01
16 Bert Wijnen by bwijnen
2002-07-30
16 Thomas Narten bert acks, he needs to find reviewer (july, 1)
2002-07-30
16 Thomas Narten A new comment added
by narten
2002-07-30
16 Thomas Narten
State Changes to Expert Review                                    from Pre AD …
State Changes to Expert Review                                    from Pre AD Evaluation                                by narten
2002-06-28
16 Stephen Coya Draft Added by scoya
2002-03-07
06 (System) New version available: draft-ietf-ipcdn-subscriber-mib-06.txt
2002-03-05
05 (System) New version available: draft-ietf-ipcdn-subscriber-mib-05.txt
2001-11-14
04 (System) New version available: draft-ietf-ipcdn-subscriber-mib-04.txt
2001-02-23
03 (System) New version available: draft-ietf-ipcdn-subscriber-mib-03.txt
2000-07-13
02 (System) New version available: draft-ietf-ipcdn-subscriber-mib-02.txt
2000-04-11
01 (System) New version available: draft-ietf-ipcdn-subscriber-mib-01.txt
1999-12-09
00 (System) New version available: draft-ietf-ipcdn-subscriber-mib-00.txt