[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ipcdn] Submission of draft 13 of Subscriber Management MIB; responses to Harrie
I've submitted a revised draft of the subscriber management MIB for i-d
publication - look for it in the usual places in the next few days. It
contains a several changes suggested by Bert and others, but the bulk of
the changes were in response to the suggestions from Harrie Hazewinkel
(8-Sept). I'm grateful to Harrie for taking the time to provide such a
detailed review; point-by-point responses are included below.
Respectfully submitted,
Wilson Sawyer
-----Original Message-----
> From: Harrie Hazewinkel [mailto:harrie@lisanza.net]
> Sent: maandag 8 september 2003 12:43
> To: Wijnen, Bert (Bert); Wilson.Sawyer@arrisi.com
> 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.
I've broken up some of the larger description clauses to try to
improve this.
> 2) adding a small description in the description clause helps, while
> now (sometimes) directly the meaning of the values is given.
I've added this for some objects; for others, a statement of what
the object *is* seemed to obscure the more rigorous statement of
what its values *do*.
> 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).
(Bert made a similar point.) The Description clauses and parts of the
text were misleading, and I think I've corrected them.
> 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.
text added to do so.
> > 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 ipcdn@ietf.org
> > 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.
moved to "Status".
> > 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.
text added.
> > 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??
I didn't add mention of Diffserv here, because (as I hope is reasonably
clear later in the document) the use of RFC3289 is as a tool to achieve
certain filtering objectives - other aspects of the diffserv framework
are incidental to this purpose. So I really don't want to dive into a
topic like "the CMTS's place in the differv framework".
> > 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.
oops. Some text that explained this in an earlier draft was omitted when
3289 was adopted as the filtering representation. Text worked back in.
> > 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.
There's always a correctness vs. clarity tradeoff. Adding "managed
objects"
anywhere in that sentence makes it more difficult to read. Unless you
(or others) think that the existing text is actually misleading, I'd
rather
leave it as is.
> > 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.
text slightly reworked to provide better linkage.
> > 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.
Strengthened the first sentence to make this clearer.
> > 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).
not sure whether the miscellaneous text changes have addressed this
point
or not.
> > 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.
The above paragraph is needed to provide the linkage and overarching
structure between these tables (back to docsSubMgtCpeIpTable), rather
than describing attributes of each table.
> > 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.
reworked. Bert made a similar point.
> > 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.
Maybe, but I think it helps to emphasize that this object is inferred
from its reference in diffServClfrElementSpecific, rather than being
the configuration knob.
> > 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'
(both wrong and missing). Fixed.
> > 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.
in this cases, I think that numbers would impede readability.
> > 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'
added.
> > 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.
The intent is to specify a default filtering behavior when unsignalled,
not no-filtering. some clarification added to the text.
> > 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.
Added definitions of upstream and downstream, to make it clear that they
correspond to ingress and egress w.r.t. the DOCSIS interface.
> > 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.
I couldn't figure out a good place to move it up to. This example is
just meant to be illustrative in any case - there are a number of other
ways to visualize the classification process.
> > 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??
maybe, but since the topic of this mib is public network protection
from subscribers, and since that includes TCP header filtering, I
thought it better to give it more prominence than it would receive
in the Security section.
> > 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.
fixed.
> > DESCRIPTION
> > "This is the CMTS centric subscriber management MIB for
> > DOCSIS compliant CMTS.
>
> Maybe extend it a bit more.
added some text.
> > 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'
fixed
> > 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.
added.
> > ::= {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"
written by my predecessor after rancorous debate. While it may be
awkward, I'm reluctant to touch it.
> > (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.
this was meant to emphasize that the learning mechanism (ARP gleaning,
source gleaning, ... ) is not specified.
> > 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.
? There's no distinction. There is only one augmented entry per cable
modem.
> > ::= { 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 }
added.
> > ::= { 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.
fixed.
> > ::= { 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 }
fixed.
> > ::= { 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 }
fixed
> > ::= { 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.
fixed.
> > ::= { 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.
added.
> > 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)
added clarifying text.
> > 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.
the descriptions of this (and the subsequent 2 OBJECT-TYPES) was
changed.
> 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?
I don't think so. In general, CMTSs must pass a qualification test
conducted by CableLabs which enforces minimum requirements. Those
requirements have always mandated full configuration access through
SNMP. I don't think a read-only compliance serves a useful purpose.
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn