Partial review of draft-ietf-ipcdn-subscriber-mib-14.txt
"Jean-Francois Mule" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
Hi Wilson,
Thanks for the update.
Below are a couple of editorial and technical comments based on draft
14 and the alpha draft15 you provided to me.
--- 1. I-D boilerplate
http://www.ietf.org/ID-Checklist.html
Per our discussion, see ID Checklist, section 2.2, especially, items 1,
10, 11 and 12.
--- 2. Use of MUST, other requirement verbs and reference to 2119
Since you have some requirements using capital MUST verbs, you should
add a section like this:
3. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
And add a normative reference for:
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
--- 3. Full spelling of the wg in the ORGANIZATION:
See MIB review guidelines section 4.5.
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines
-03.txt
< ORGANIZATION "IETF IPCDN Working Group"
> ORGANIZATION "IETF IP over Cable Data Network (IPCDN)
> Working Group"
--- 4. Nits
- consider using "MIB module" instead of "MIB" when you mean the subs.
mgmt part of the MIB
- DOCSIS should be all capital (global search/replace, I found one bad
occurrence)
-
--- 5. Technical - important
Since RFC 2669 will be replaced by the cable device v2 RFC at
publication, did you double-check that all the objects you are
referencing (or using) from RFC 2669 are still "current" in the latest
ID?
In section 2.2.1, I found 1 instance where the above comment raises a
concern for docsDevCpeIp (my comments start with #):
o docsDevCpeEnroll
# ok, this object is current.
o docsDevCpeIpMax
# ok, this object is current.
o docsDevCpeIp
# this one object is now deprecated from the RFC update. We should
# probably mention the replacement: docsDevCpeInetTable table or
# its equivalent in that table or mention both.
--- 6. Add an IANA consideration section
A new IANA consideration section is now required, see ID checklist 2.2
#7.b.
Suggestion:
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER Value
---------- -----------------------
docsSubMgt { mib-2 xx }
Editor's Note (to be removed prior to publication): the IANA is
requested to assign a value for xx under the mib-2 subtree and to
record the assignment in the SMI Numbers registry. When the
assignment has been made, the RFC Editor is asked to replace xx (here
and in the MIB module) with the assigned value and to remove this
note.
--- 7 . CableLabs Spec references: add archives URL
For all CableLabs Spec' references, also add the following URL:
http://www.cablelabs.com/specifications/archives/
(the main reason here is that if some specs get updated, readers will be
able to find the referenced versions in the archive repository).
--- 8. SMIC compilation errors
Compiles clean except for those kinds of compilation errors:
E: f(subs.mi2), (525,25) a bit or enum list is not allowed on a TC
For e.g.
MODULE DIFFSERV-MIB -- RFC3289
MANDATORY-GROUPS {
diffServMIBDataPathGroup,
diffServMIBClfrGroup,
diffServMIBClfrElementGroup,
diffServMIBMultiFieldClfrGroup,
diffServMIBActionGroup,
diffServMIBAlgDropGroup,
diffServMIBCounterGroup
}
OBJECT diffServDataPathStatus -- same as RFC3289
SYNTAX RowStatus { active(1) }
-- ># E: f(subs.mi2), (525,25) a bit or enum list is not allowed on a TC
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
I don't see the issue and don't have time to dig but the SMI you have
looks good to me and is in sync with what is in RFC 3289. Just wanted to
point this out though.
That's all I could see in the time I could allocate for the review.
Jean-Francois.
> -----Original Message-----
> From: Wilson Sawyer [mailto:[email protected]]
> Sent: Monday, September 06, 2004 7:56 AM
> To: Wijnen, Bert (Bert)
> Cc: [email protected]; Ipcdn (E-mail); Jean-Francois Mule;
> Richard Woundy @ Comcast
> 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
>
>