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

Looks good to me.

Thanks, Bert


> -----Original Message-----
> From: Wilson Sawyer [mailto:[email protected]]
> Sent: Monday, September 06, 2004 15:56
> To: Wijnen, Bert (Bert)
> Cc: [email protected]; Ipcdn (E-mail); [email protected];
> [email protected]
> Subject: Re: AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt
> 
> 
> Bert - I hope to have Jean-Francois' comments and have them 
> incorporated in time for
> submission by Wednesday. Here are specific responses to your 
> comments (interspersed):
> 
> The other changes so far include:
> -- IPR and copyright boilerplate changes
> -- updated reference to BPI+ spec.
> 
> - 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
> >
> 
> Added these to the IMPORTS clause as suggested.
> 
> 
> >
> > 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?
> >
> 
> That paragraph reworded to:
> 
>     If docsSubMgtCpeControlActive is true and a CMTS receives
>     an IP packet from a CM that contains a source IP address which
>     does not match one of the docsSubMgtCpeIpAddr entries for this
>     CM, one of two things occurs.  If the number of entries is less
>     than docsSubMgtCpeControlMaxCpeIp, the source address is added to
>     the table and the packet is forwarded.  If the number of entries
>     equals the docsSubMgtCpeControlMaxCpeIp, then the packet is
>     dropped."
> 
> >
> > 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.
> >
> 
> now reads:
> 
>     For each of the columns in this table, zero is a distinguished
>     value, indicating that the default filtering action is to be
>     taken, rather than that associated with a filter group number.
>     Zero is used if the filter group is not signaled by DOCSIS
>     registration.
> 
> >
> > 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.
> 
> renamed, per your last exchange with Eduardo, to:
> 
>     docsSubMgtCmFilterSubDownstream
>     docsSubMgtCmFilterSubUpstream
>     docsSubMgtCmFilterCmDownstream
>     docsSubMgtCmFilterCmUpstream
> 
> >
> > 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.
> 
> I was mistaken regarding the signaled width of this item - it 
> is actually 2 octets. I
> changed the range to 1..65535 to match the actual signaled width.
> 
> >
> > 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.
> >
> 
> done.
> 
> >
> > 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.
> 
> changed to:
> 
> Effective network filtering of TCP traffic requires that implementors
> MUST follow the recommendations in section 2.2.6.
> 
> 
> >
> > Thanks,
> > Bert
>