Re: Changes for next RFI v2 MIB (draft 10)

Hi -

I was able to extract the text from that PDF file, so I have
some more detailed comments in-line below.

> From: "Eduardo Cardona" <[email protected]>
> To: "Donati Andrew-MGIA0477" <[email protected]>; <[email protected]>
> Sent: Monday, April 12, 2004 3:51 PM
> Subject: [ipcdn] Changes for next RFI v2 MIB (draft 10)
...
> Change #2
> docsIfCmtsModulationEntry OBJECT-TYPE
...
> Initial default entries may be created at system

I think you mean "MAY"

> initialization time, which could report for a value
> 'permanent' or 'readOnly' for docsIfCmtsModStorageType.

Is "could report" intended to mean that this is the complete
set of values that can be returned by a conformant implementation?

> A CMTS may not allow the creation of additional Interval
> Usage Codes for a modulation profile being defined at
> Initialization time.

Does "may not" here mean "MUST NOT" or "MAY"?

...
> Note that some objects do not have default value ,

 I think you mean "values"

...
> upstream channels, the value of docsIfCmtsModChannelType
> MUST NOT be changed.

This is ambiguous.  Three readings possible:
   a) agent must not change the value it reports over time
   b) agent must not permit SET requests to modify the value
   c) both (a) AND (b)

...
> MUST NOT be set to destroy(6) or notInService(2)."

ditto

...

> CHANGE # 5
> docsIfUpChannelStatus OBJECT-TYPE
...
> 1. Entries with this object set to active(1) are
> logically linked to a defined physical interface in
> the interface MIB RFC 2863, no temporarily created to
> clone parameters.

I think you mean "not" instead of "no".
(Even so, as a non-expert, it's still unclear to me what
this sentence is supposed to mean.)

> 2. A status transition from active(1) to notInService(2)
> or destroy(6) is not permitted.

??? So how DOES one get rid of these things???

> 3. ifAdminStatus from the Interface MIB RFC 2863 should be
> used to take an Upstream Channel offline.

I assume you mean "SHOULD".  What other mechanisms
can take an Upstream Channel offline?

> 4. Temporary inactive rows must be created using
> createAndWait(5).

I think you mean "MUST".  The conformance material
should reflect that the value createAndGo is not permitted.

> 5. The only possible status change of a row created using
> createAndWait(5) (i.e. notInService(2)) or notReady(3)
> is to destroy(6).

So how does it get to be active?  (see number 2 above)

> 6. Temporary created rows must never be given the status
> active(1).

I have trouble reconciling this with 2 above.  In general,
this is a *very* confusing DESCRIPTION.

> A Mandatory procedure for adjusting an specific physical
> Upstream channel is:

why is "mandatory" capitalized?

> 1. Create a temporary row through an SNMP SET using
> createAndWait(5). Use an ifIndex value outside the
> operational range of the system.

How is the "operational range" determined?

> 4. Update the physical row by setting the object
> docsIfUpChannelUpdate to true(1). This operation fails
> with error genErr if the adjusted parameters are not
> compatible with each other.

My reading of RFC 3416 section 4.2.5 (10) is that
inconsistentValue would be more appropriate.

> 5. Delete the temporary row through an SNMP SET using
> DELETEdestroy(6). Temporary entries need not persist
> at reinitialization of the managed system."

Optional persistence isn't helpful for interoperability.  In
this particular case, it sounds like persistence would be
inappropriate, particularly given RFC 2579's page 16.

...
> CHANGE #6
> docsIfQosProfileEntry OBJECT-TYPE
...
> An entry in this table must not be removed while it is

MUST NOT?

> An entry in this table should not be changeable while

SHOULD NOT?

> it is referenced by an entry in docsIfCmtsServiceTable.
> If this table is created automatically, there should only

SHOULD?

> be a single entry for each Class of Service. Multiple
> entries with the same Class of Service parameters are not
> recommended."

NOT RECOMMENDED?

...
> MIN-ACCESS read-only for docsIfDownstreamChannelTable implies the minimal
> implementation has no persistent requirement.
> Persistence makes sense only in the case of MAX-ACCESS read-write support.

I don't understand how you come to this conclusion.

...
> CHANGE # 7
> docsIfDownstreamChannelEntry OBJECT-TYPE
...
> The CMTS ability to retain SNMP SETs for read-write values
> after system reinitialization is implementation dependant."

This is what StorageType is for.

...
> CHANGE # 8
> docsIfCmtsMacEntry OBJECT-TYPE
...
> The CMTS ability to retain SNMP SETs for read-write values
> after system reinitialization is implementation dependant."

This is what StorageType is for.

> docsIfCmtsServiceTable
> Object docsIfCmtsServiceAdminStatus is read-write, and indicates the
> administrative Status of an active CM upstream queue service, upon reboot all

The ", upon" should be ".  Upon"

> queues are deleted and CMs will re-register. Persistence is not needed. The

One sentence appears to prohibit persistence, and the following sentence
says it's optional.  I prefer the former over the latter.

> docsIfCmMacTable
> This is a CMs specific object.
> docsIfCmRangingTimeout MAX-ACCESS is read-write with DEFVAL clause.
> It is believed that the presence of the DEFVAL and the MIB object reference to
> the spec is sufficient to not detail CM persistent requirements.

I'm unable to parse this sentence.

...

Randy