Subject: [ipcdn] FW: review: draft-ietf-ipcdn-mib.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 10 Sep 2003 09:14:36 +0200

Here is additional MIB doctor review.
Harrie was involved a lot with the Diffserv MIB work,
so I asked him explicitly to look at that aspect.

Thanks to Harrie for his review.

Pls copy Harrie explicitly on any comments/answers, cause I doubt
that he is on the IPCDN mailing list.

Thanks,
Bert 

-----Original Message-----
From: Harrie Hazewinkel [mailto:[email-masked]]
Sent: maandag 8 september 2003 12:43
To: Wijnen, Bert (Bert); [email-masked]
Cc: Harrie Hazewinkel
Subject: review: draft-ietf-ipcdn-mib.txt

HI,

Hereby my MIB review. While reading I added comments in-line in the 
document.
(Sorry, if a big part of the draft is copied, but provides context I 
hope.)

Some general (summary of) comments are:
1) the formatting of the description clauses could improve readability.

2) adding a small description in the description clause helps, while
now (sometimes) directly the meaning of the values is given.

3) the DIFFSERV-MIB (classifier) connections seems odd to me.
I do not beleive it is correct, also since the text speaks of
OIDs and that is no where used (only Integer).
IMHO, the docsSubMgtCmFilterTable could work like the 
diffServDataPathTable
and with Rowpointer for is objects and the docsSubMgtFilterGroupTable
becomes redandant or could acts as a pool of filter available (but then
needs RowPointers as weel). This sounds simpler to me and does the job.
Please correct, me if I am wrong or ask if more info is needed.
(Below I have more specifics of this).

Hope this helps,
Harrie

> Abstract
>
>    This memo defines a portion of the Management Information Base (MIB)
>    for use with network management protocols in the Internet community.
>    In particular, it defines a set of managed objects for SNMP-based
>    management of Data-over-Cable Service Interface Specification
>    (DOCSIS)-compliant Cable Modem Termination Systems. These managed
>    objects facilitate protection of the cable network from misuse by
>    subscribers.

Not sure, but is not a subset of managed objects addressed here?
Maybe it is useful to mention it extends the other MIBs.

>
>    This memo is a product of the IPCDN working group within the 
> Internet
>    Engineering Task Force.  Comments are solicited and should be
>    addressed to the working group's mailing list at [email-masked]
>    and/or the author.

This goes out of the abstract, I presume??
It is mostly part of the 'Status of the memo' which
gets changed when it turns into an RFC.

> 2. Overview
>
>    This MIB provides a set of objects required for the management of
>    DOCSIS Cable Modem Termination Systems (CMTS). The specification is
>    derived in part from the operational model described in the DOCSIS
>    Radio Frequency Interface Specification [DOCSRFI]. These managed
>    objects facilitate protection of the cable network from misuse by
>    subscribers.

What kind of 'misuse'? Maybe it is useful to define the kinds of
misuse is ment here.

>    The following figure illustrates the operational and physical
>    deployment relationships between elements in a cable modem network.
>    This MIB resides at the CMTS, which is the first point in the public
>    data network at which the cable operator controls physical access.
>    The CMTS (possibly assisted by other IP services devices) acts as a
>    network edge, separating the physical outside-plant cable television
>    network from the operator's IP network.
>
>
>                     |              operator's IP network
>                  +------+          ---------------------
>                  | CMTS |          operator's cable head-end
>                  +------+          ---------------------
>                     |
>            +--------+--------+     CATV physical network
>            |        |        |
>          +----+   +----+   +----+  ------------------
>          | CM |   | CM |   | CM |  subscriber premises
>          +----+   +----+   +----+  ------------------
>            |        |        |     subscriber host or network
>
>
>    This MIB controls IP packet forwarding to and from each cable modem,
>    at the CMTS. Different modems may be accorded different treatment.

Maybe time to refer to DIFFSERV??

>    Much of this MIB duplicates capabilities found in the DOCSIS Cable
>    Device MIB [RFC2669].

Why duplication? Is it not possible to use those managed objects?
Otherwise, I beleive it is a good idea to mention why they are
duplicated.

>    While it is expected that the Cable Device MIB
>    will be used to prevent unwanted traffic from entering the cable
>    network, it is also possible that a malicious user might tamper with
>    cable modem software, disabling its filtering policies. This MIB
>    provides a more secure mechanism, since physical access to the CMTS
>    is controlled by the network operator.

Actually, I do not believe this MIB provides the 'secure mechanism', but
merely the managed objects to manage that 'secure mechanism'.
IMHO, it gives a not fully correct impression.

>
>    In particular, this MIB provides two capabilities: first, to limit
>    the IP addresses behind a modem, and, second, to provide protocol
>    filtering to and from a modem. The first duplicates the capabilities
>    of the docsDevCpe group [RFC2669]. This provides for either learned
>    or provisioned subscriber premises host IP addresses behind a cable
>    modem.

The second?? Which is below the 'filtering', but mention it as such.
It helps the reader.

>    The filtering capability makes use of the Classification, Counting,
>    and Drop facilities of the Differentiated Services MIB [RFC3289]. In
>    order to provide different filtering for various classes of
>    subscribers, this MIB defines the docsSubMgtFilterGroupTable which
>    specifies which filters are to apply to each subscriber packet.  
> This
>    table is used by RFC3289 as a first pass of classification, to then
>    choose a second pass of classification using the

Here I am getting confused from the text.
'This table is used by RFC3289...' makes me believe this extends the
MIB defined in RFC 3289. But my understanding is that you want to use
the 'filtering' of the DIFFSERV-MIB in this MIB, right.
I suggest to rewrite this paragraph to reflect this.

>    diffServMultiFieldClfrTable:
>
>    diffServDataPathStart --> diffServClfrEntry(1)
>    diffServClfrElementSpecific(1) --> docsSubMgtFilterGroupIndex
>    diffServClfrElementNext(1) --> diffServClfrEntry(2)
>    diffServClfrElementSpecific(2)--> diffServMultiFieldClfrEntry
>    diffServClfrElementNext(2) --> difServActionEntry (count or algDrop)

>
>    Rather than maintaining a separate list of filters for each modem at
>    the CMTS, it is assumed that large numbers of modems will share
>    filtering characteristics. Therefore, DOCSIS signaling defines 
> filter
>    groups by which cable modems share common filter lists.

I am not sure, but if I understand it correctly what you want the above 
section
needs to be improved.
What I understand (in short) is this MIB does 2 things 1) limit IP 
addresses
of a modem and 2) does filtering. The first part is also done by 
RFC2669 and
is here duplicated. The second part is filtering as defined in RFC3289 
(where it
is DIFFSERV focussed).

>
> 2.1. Structure of the MIB
>
>    This MIB is structured in four tables:
>
>    o    The docsSubMgtCpeControlTable controls the acceptance of
>         subscriber host addresses behind a cable modem.
>
>    o    The docsSubMgtCpeIpTable monitors the subscriber host addresses
>         which the CMTS believes to exist behind the cable modem.
>
>    o    The docsSubMgtCmFilterTable binds a cable modem to a set of
>         filters in diffServMultiFieldClfrTable.
>
>    o    The docsSubMgtFilterGroupTable provides the OIDs by which
>         the diffServClfrElementTable selects a filter group.
>
>    The docsSubMgtCpeControlTable and docsSubMgtCmFilterTable AUGMENT 
> the
>    docsIfCmtsCmStatusTable from [RFC2670]. Similarly,
>    docsSubMgtCpeIpTable expands this table (an additional index is
>    used). As such, each entry in these tables is bound to a registered
>    cable modem, as perceived by the CMTS.

I would break to above in a section for each of the tables above.
It took me sometime to realize that the above paragraph covers the
first three tables. Or just extend the 'points' since it is
not that much text anyway.

> 2.1.1. docsSubMgtFilterGroupTable
>
>    The docsSubMgtFilterGroupTable is unusual in that it might be viewed
>    not so much as an array of single-object entries as an array of
>    OBJECT-IDENTIFIER conventions. Each instance of
>    docsSubMgtFilterGroupIndex serves as an OID reference for
>    diffServClfrElementSpecific. The index value corresponds to the
>    filter group identifier signaled by the cable modem [DOCSRFI].  An
>    entry exists in this Table if a reference to it exists in
>    diffServClfrElementSpecific.

When looking in the MIB I do not see the OID reference.
See also there.

>
>    As such, contrary to common practice, the index for the table is
>    read-only, and is both the Entry's index and its only value.

Not needed here. Only later in the OBJECT-TYPE. I do not
know the access here at all.

> 2.2. Management requirements
>
>    The DOCSIS cable modem provisioning model [DOCSRFI] requires that
>    cable modems use TFTP to acquire a list of parameters. The modem 
> then
>    passes many of these parameters to the CMTS in the DOCSIS
>    Registration message. The parameter values are digitally signed by
>    the creator of the TFTP contents, and the signature is verified by
>    the CMTS. In general, then, the CMTS need not itself be configured
>    with the attributes of its cable modems. It will acquire these 
> values
>    through the Registration process that is secured by the digital
>    signature.
>
>    Cable modem subscriber management, as described here, modifies this
>    process slightly for reasons of data reduction and ease of
>    administrative control.  In the case of filtering management, for

What is ment by 'filtering management'?
Is it 'management of the filtering mechanism' or filtering the 
management
traffic'?

>    example, the tables are maintained through SNMP at the CMTS, and the
>    modem registration merely signals the index values for the rows that
>    apply to that modem.
>
> 2.2.1. Interaction with DOCSIS provisioning for CPE address control
>
>    Rows in docsSubMgtCpeControlTable are created by the CMTS for each
>    modem as a result of the DOCSIS registration process. The DOCSIS
>    registration attributes may include items semantically equivalent to
>    those in the DocsDevCpe branch of the DOCSIS Cable Device MIB
>    [RFC2669]:
>
>    o    docsDevCpeEnroll
>    o    docsDevCpeIpMax
>    o    docsDevCpeIp
>
>    Successful DOCSIS registration shall have the effect of setting the
>    corresponding fields in the docsSubMgtCpeControlTable and the
>    docsSubMgtCpeIpTable. If not present, the default at registration
>    shall be to set docsSubMgtCpeControlActive to false.

I believe something in this sentence is wrong/missing.
'default' -> 'default behavior'

>    Rows in docsSubMgtCpeIpTable are created through any of three ways:
>   DOCSIS registration (as described above), learning by the CMTS, or
>    through some unspecified administrative mechanism on the CMTS.

Maybe adding below numbers? Like,..
1) DOCSIS registration (as described above), 2) learning by the CMTS,
  3) or through some unspecified administrative mechanism on the CMTS.

>  The
>    docsDevCpeIpMax table bound applies only to the first two.
>
>    The CMTS may learn addresses by simply snooping source IP addresses
>    from each cable modem. Other learning mechanisms (for example, ARP

Suggestion,
'from each cable modem' -> 'from traffic originating from each cable 
modem'

>    snooping) may be used. The learning mechanism is not defined by this
>    document.
>
> 2.2.2. Interaction with DOCSIS provisioning for filtering
>
>    Rows in docsSubMgtCmFilterTable are created by the CMTS for each
>    modem as a result of the DOCSIS registration process. The DOCSIS
>    registration attributes may include four indices (see section
>    C.1.1.18.3 of [DOCSRFI]):
>
>    o   one identifying the upstream filter group for packets
>        originating from the cable modem (i.e., those packets whose
>        source MAC address matches that of the cable modem).
>    o   one identifying the upstream filter group for packets
>        originating from subscribers attached to the cable modem (i.e.,
>        those packets whose source MAC address does not match that of
>        the cable modem).
>    o   one identifying the downstream filter group for packets
>        destined to the cable modem (i.e., those packets whose
>        destination MAC address matches that of the cable modem).
>    o   one identifying the downstream filter group for packets
>        destined to subscribers attached to the cable modem (i.e.,
>        those packets whose destination MAC address does not match
>        that of the cable modem).
>
>    Successful registration shall have the effect of setting
>    docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream,
>    docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream, for
>    that modem (just as if set through the SNMP protocol). If the DOCSIS
>    attributes are not present, the effect shall be to use the default
>    entry (diffServClfrElementSpecific=zeroDotZero) specified in the
>    diffServClfrElementTable.

(diffServClfrElementSpecific=zeroDotZero) is not a default entry.
zeroDotZero is a default value for the diffServClfrElementSpecific
when no filtering is done or known.
I also believe that is no filtering is done the values of
docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream,
docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream can be 
zero.
There is no need for a reference into DIFFSERV-MIB filters/classifiers 
then.

Not sure if I am correct here, if so the text needs some changes I 
guess.

> 2.2.3. Distinguishing Modem from Subscriber Traffic
>
>    All traffic originating from or destined to a subscriber site is
>    potentially suspect, and subject to suppression by the network
>    operator.  This is true even if the traffic is ostensibly sourced or
>    sunk by the cable modem itself, rather than the subscriber hosts
>    behind the modem. To provide more nuanced administrative control,
>    this document allows separate filter policies for modems and hosts.
>    For example, modem policies may limit modems to server-subnet-only
>    access, while allowing a different scope to subscribers.
>
>    The CMTS chooses the filter set to apply based solely on the MAC
>    address (source MAC upstream, destination MAC downstream). If the 
> MAC
>    address matches that of the modem, then the
>    docsSubMgtCmFilterUp/Downstream pair is used; otherwise the
>    docsSubMgtSubFilterUp/Downstream pair is applied.
>
>    If the CM acts as a router rather than as a DOCSIS bridging
>    forwarder, then the network operator will only use the
>    docsSubMgtCmFilterUp/Downstream pair.
>
> 2.3. Relationship to the Differentiated Services MIB [RFC3289]
>
>    DOCSIS CMTSs rely on the classification, counting, and drop
>    facilities of the Differentiated Services MIB to screen subscriber
>    packets for IP, TCP, and UDP characteristics. It is expected that 
> any
>    implementation of this MIB also include at least the following from
>    RFC 3289:
>
>    o    diffServDataPathTable

I am not sure why this table is needed. Be aware that this table has
ifDerection, but the direction as such is not equal as used here.
Here we have 'upstream/downstream'. As a result or we need to specify
a mapping here, or we can directly use the 'diffServDataPathStart'
mechanism to add in the MIB here defined the RowPointer that points
to an diffSrvrClfrEntry.

>    o    diffServClfrTable
>    o    diffServClfrElementTable
>    o    diffServMultiFieldClfrTable
>    o    diffServActionTable
>    o    diffServCountActTable
>    o    diffServAlgDropTable (diffServAlgDropType=alwaysDrop)
>
>    The corresponding "next-free" objects are also required.
>
>    The use of other facilities from RFC 3289 is not precluded, but is
>    beyond the scope of this specification.
>
> 2.3.1. Using the Filter Group to Extend Packet Classification
>
>    The base capability of RFC 3289 assumes that all packets on the same
>    direction of the same interface will be classified by the same
>    criteria. Filter Groups, introduced in this document, expand on RFC
>    3289 to allow various subscribers to receive different 
> classification
>    (filtering) treatment. One way to view filter groups is as sub-
>    interfaces within the physical DOCSIS channel. Another way to view
>    them is as values of a field logically prepended to the packet prior
>    to classification:
>
>    [filter group][docsis MAC header][IP header]...
>
>    Of course this 'logical' field has no existence outside of the CMTS.
>
>    The diffServClfrTable and diffServClfrElementTable are then used
>    twice: the first classifiers select among filter groups, using OIDs
>    from docsSubMgtFilterGroupTable. The 'next' action on matching a
>    filter group is to select a diffServClfrEntry which now classifies 
> on
>    IP/TCP/UDP criteria (the diffServMultiFieldClfrTable_.  The 'next'
>    action on this second match may be a 'count' (and accept), a 'drop',
>    or some other feature from RFC 3289.

IMHO, the approach described here as filtering needs to be move to
the introduction where one speaks of 'filtering'. There is no
need to specify the managed objects then, but just the approach,
which is [filter group][docsis MAC header][IP header]...
It will clarify way more (as a non DOCSIS expert) and guides the
reader towards what is accomplished.

>
> 2.3.2. Interface Usage
>
>    For purposes of DOCSIS subscriber management, only the DOCSIS MAC
>    cable interface(s) are used. The interface appears as the index to
>    diffServDataPathEntry, which is the starting point for diffserv MIB
>    table traversal.

Somehow one can figure it out, but since there is a mismatch by the
words/terms used the mapping 'egress/ingress' to 'down/upstream'
needs to be defined.

>    The use of the diffserv MIB for other purposes, both on the DOCSIS
>    MAC interfaces and on other network interfaces, is not precluded by
>    this document.
>
> 2.4. Filtering and the Tiny Fragment Attack

[snip]
Is this section not for the security consideration??

> 3. Definitions
>
>    DOCS-IETF-SUBMGT-MIB  DEFINITIONS ::= BEGIN

In this MIB module I would format the DESCRIPTIONs a bit better, by
adding emtpy lines between pieces of text. Now it is sometimes a bit
difficult to read.

Also sometimes object directly define what each value means, but not
a small generic description of the object itself. For instance,
docsSubMgtCpeControlActive is a good example of this.

>    IMPORTS
>            InetAddressType,
>            InetAddress
>                    FROM INET-ADDRESS-MIB

Needs a normative reference of the RFC 2851 of the imported MIB.

>        DESCRIPTION
>            "This is the CMTS centric subscriber management MIB for
>        DOCSIS compliant CMTS.

Maybe extend it a bit more.

>    docsSubMgtCpeControlTable OBJECT-TYPE
>        SYNTAX  SEQUENCE OF DocsSubMgtCpeControlEntry
>        MAX-ACCESS not-accessible
>
>        STATUS  current
>        DESCRIPTION
>            "This table AUGMENTs the docsIfCmtsCmStatusTable and adds

The 'and' makes it look like it is doing two things, but it is infact 
doing
1 thing, 'AUGMENTING a table with 4 objects'

>        four WRITEable objects which reflect the state of subscriber
>        management on a particular CM."
>        ::= { docsSubMgtObjects 1 }
>
>    docsSubMgtCpeControlEntry OBJECT-TYPE
>        SYNTAX  DocsSubMgtCpeControlEntry
>        MAX-ACCESS not-accessible
>        STATUS  current
>        DESCRIPTION
>            "A row in the docsSubMgtCpeControlTable.  All values are set
>        at successful modem registration, either from the system 
> default,
>        or from objects included in the DOCSIS registration request sent
>        upstream to the CMTS from the CM. The contents of this entry are
>        meaningless unless the corresponding docsIfCmtsCmStatusValue is
>        registrationComplete(6). The persistence of this row is
>        determined solely by the lifespan of the corresponding
>        docsIfCmtsCmStatusEntry (normally StorageType=volatile)."
>        AUGMENTS { docsIfCmtsCmStatusEntry }

Since 'docsIfCmtsCmStatusValue' is not imported a REFERENCE would
be usefull in order to find that object.

>        ::= {docsSubMgtCpeControlTable 1 }

>    docsSubMgtCpeControlMaxCpeIp OBJECT-TYPE
>        SYNTAX  Integer32(0..2147483647)
>        MAX-ACCESS read-write
>        STATUS  current
>        DESCRIPTION
>            "The number of simultaneous IP addresses permitted behind
>        the CM. If this is set to zero, all CPE traffic from the CM is
>        dropped.  If the provisioning object corresponding to
>        docsSubMgtCpeIpTable includes more CPE IP address entries for
>        this modem than the value of this object, then this object is
>        set to the count of the number of rows in docsSubMgtCpeIpTable
>        that have the same docsIfCmtsCmStatusIndex value.

The above sentence is hardly to understand and I believe it
just want to express that "the value equals the amount of rows
in docsSubMgtCpeIpTable that have the same docsIfCmtsCmStatusIndex 
value"

> (E.g. if the
>        CM has 5 IP addresses specified for it, this value is 5). This
>        limit applies to learned and docsis-provisioned entries, but
>        does not limit entries added through some administrative
>        process at the CMTS. If not set through DOCSIS provisioning,
>        this object defaults to docsSubMgtCpeMaxIpDefault. Note that
>        this object is only meaningful if docsSubMgtCpeControlActive
>        is true."

Is a DEF-VAL not useful. I am only not sure how this can be done.
DEF-VAL does not allow a reference to a value. :-((

>        ::= { docsSubMgtCpeControlEntry 1 }

>    docsSubMgtCpeControlLearnable OBJECT-TYPE
>        SYNTAX  TruthValue
>        MAX-ACCESS read-write
>        STATUS  current
>        DESCRIPTION
>            "If this is set to true, the CMTS may learn up to
>        docsSubMgtMaxCpeIp addresses (less any DOCSIS-provisioned
>        entries) related to this CM.  Those IP addresses are added (by
>        internal process) to the docsSubMgtCpeIpTable. The nature of the
>        learning mechanism is not specified here.

IMHO, '(by internal process)' is also part of the 'The nature ...'
As a result it is redundant and maybe deleted.

>  If not set through
>        DOCSIS provisioning, this object defaults to
>        docsSubMgtCpeLearnableDefault. Note that this object is only
>        meaningful if docsSubMgtCpeControlActive is true."
>        ::= { docsSubMgtCpeControlEntry 3 }
>
>    docsSubMgtCpeControlReset OBJECT-TYPE
>        SYNTAX  TruthValue
>        MAX-ACCESS read-write
>        STATUS  current
>        DESCRIPTION
>            "This object always returns false on read.  If this object 
> is
>        set to true, the rows with  'learned' addresses in
>        docsSubMgtCpeIpTable for this CM are deleted from that table."

Does this count for all addreses 'learned' or only those addresse 
'learned'
to which this augmented entry applies.
Maybe usefull to specify.

>        ::= { docsSubMgtCpeControlEntry 4 }
>
>    docsSubMgtCpeControlLastReset OBJECT-TYPE
>        SYNTAX  TimeStamp
>        MAX-ACCESS read-only
>        STATUS  current
>        DESCRIPTION
>            "The value of sysUpTime when docsSubMgtCpeControlReset was
>        last set true. Zero if never reset."

DEF-VAL { 0 }

>        ::= { docsSubMgtCpeControlEntry 5 }
>
>    docsSubMgtCpeMaxIpDefault OBJECT-TYPE
>        SYNTAX  Integer32(0..2147483647)
>        MAX-ACCESS read-write
>        STATUS  current
>        DESCRIPTION
>            "The default value for docsSubMgtCpeControlMaxCpeIp if not
>        signaled in the DOCSIS Registration request. Upon initial CMTS
>        initialization, this defaults to 16."

Use "DEF-VAL { 16 }" to indicate the 'this defaults to 16' the text is
redundant then.

>        ::= { docsSubMgtObjects 2 }
>
>    docsSubMgtCpeActiveDefault OBJECT-TYPE
>        SYNTAX  TruthValue
>        MAX-ACCESS read-write
>        STATUS  current
>        DESCRIPTION
>            "The default value for docsSubMgtCpeControlActive if not
>        signaled in the DOCSIS Registration request. Upon initial CMTS
>        initialization, this defaults to false."

DEF-VAL { false }

>        ::= { docsSubMgtObjects 3 }
>
>    docsSubMgtCpeLearnableDefault OBJECT-TYPE
>        SYNTAX  TruthValue
>        MAX-ACCESS read-write
>        STATUS  current
>        DESCRIPTION
>            "The default value for docsSubMgtCpeControlLearnable if not
>        signaled in the DOCSIS Registration request. Upon initial CMTS
>        initialization, this defaults to true."

DEF-VAL { true }

>        ::= { docsSubMgtObjects 4 }
>
>    docsSubMgtCpeIpTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF DocsSubMgtCpeIpEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "A table of CPE IP addresses known on a per CM basis."
>        ::= { docsSubMgtObjects 5 }

>    docsSubMgtCmFilterTable OBJECT-TYPE
>        SYNTAX  SEQUENCE OF DocsSubMgtCmFilterEntry
>        MAX-ACCESS not-accessible
>        STATUS  current
>        DESCRIPTION
>            "Binds filter groups to modems. This table identifies for
>        each modem the upstream and downstream filter groups that apply
>        to packets for that modem. Zero is used as a distinguished value
>        to mean no filter group."

'Zero ....group.' makes no sense to me here.

>        ::= { docsSubMgtObjects 6 }
>
>    docsSubMgtCmFilterEntry OBJECT-TYPE
>        SYNTAX  DocsSubMgtCmFilterEntry
>        MAX-ACCESS not-accessible
>        STATUS  current
>        DESCRIPTION
>            "Binds a filter group to each direction of traffic for a
>        modem. The filters in this entry apply if
>        docsSubMgtCpeControlActive is true. The contents of this entry
>        are meaningless unless the corresponding

Since 'docsIfCmtsCmStatusValue' is not imported a REFERENCE would
be usefull in order to find that object.

>        is registrationComplete(6). The persistence of this row is
>        determined solely by the lifespan of the corresponding
>        docsIfCmtsCmStatusEntry (normally StorageType=volatile)."
>        AUGMENTS { docsIfCmtsCmStatusEntry }
>        ::= {docsSubMgtCmFilterTable 1 }
>
>
>    docsSubMgtSubFilterDownstream OBJECT-TYPE
>        SYNTAX  Integer32(0..2147483647)
>        MAX-ACCESS read-write
>        STATUS  current
>        DESCRIPTION
>            "The filter group applied to traffic destined for 
> subscribers
>        attached to the referenced CM.  This is set upon row creation to
>        either zero (use default classification), or to the value in the

What is considered default classification? (Also for 
docsSubMgtSubFilterUpstream,
docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream)

>    docsSubMgtFilterGroupTable OBJECT-TYPE
>        SYNTAX  SEQUENCE OF DocsSubMgtFilterGroupEntry
>        MAX-ACCESS not-accessible
>        STATUS  current
>        DESCRIPTION
>            "Provides a collection of OIDs to which
>        diffServClfrElementSpecific refers. This table provides filter
>        group indices which can be compared with those signaled during
>        Docsis registration. A packet matches an entry from this table
>        if the packet originated from or is destined to a cable modem
>        which registered this index as one of its four filter groups
>        (see docsSubMgtCmFilterTable) and if the packet direction and
>        MAC address select the use of this index among the four."

I am not seeing the use of this table and seems to me connected in
a strange way to the diffServClfrElementEntry. It speaks of a 
collection of
OIDs, but the table has only Integer. This is confusing.

Not sure, yet what the best way is in order to change this table.
(I am thinking about it, but any extra explaination of the
auther could enlighten it for me).

Some option, I am thinking of deleting this table, use the 
diffServClfrTable
directly and change the docsSubMgtSubFilterDownstream, 
docsSubMgtSubFilterUpstream,
docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream into 
RowPointers.
That table would then function like the diffServDataPathTable.

>    docsSubMgtFilterGroupIndex OBJECT-TYPE
>        SYNTAX  Integer32(0..2147483647)
>        MAX-ACCESS read-only
>        STATUS  current
>        DESCRIPTION
>            "Provides an OID to which diffServClfrElementSpecific

Why using the SYNTAX-TYPE Interger32? I would believe this must be an
RowPointer.

>        refers. A packet matches this entry if the packet's cable modem
>        registered this index value as one of its four filter groups
>        and if the packet direction and MAC address select the use of
>        this index among the four.

Not sure, but is here a pointer to the 'diffServClfrElementSpecific'
what is needed followed

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

Cool, this is usefull. Many would ask 'Why?'.

>        ::= { docsSubMgtFilterGroupEntry 1 }
>
>
>    docsSubMgtBasicCompliance MODULE-COMPLIANCE

Would be the creation of a 'FullCompliance' and 'ReadOnlyCompliance'
make sense?

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn