Re: AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt

Bert - thanks for the comments. The only one that I wonder about is your #4 (hard limit of
1-255 for FilterGroupIndex). Since this is driven directly from a one-octet field in a
DOCSIS signaling packet, I thought it confusing to allow a broader range in the MIB.
[analogy: rfc2013:udpLocalPort INTEGER (0..65535)] Granted, we may one day change the
DOCSIS protocol, or find some other way to use this table that doesn't rely on the protocol
field, but this seemed a lesser danger than the confusion of mismatched ranges. In actual
deployment, the set of values is more likely to be something like 1-10, so there's plenty
of headroom unless usage is radically rethought.

- Wilson

"Wijnen, Bert (Bert)" wrote:

> 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