Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management
draft-ietf-ipcdn-subscriber-mib-16

[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.

[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.

[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.

[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.

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.

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

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.

-----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

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.

State Changes to Expert Review                                    from Pre AD Evaluation                                by narten