Subject: [ipcdn] Changes for next RFI v2 MIB (draft 10)

From: "Eduardo Cardona" <[email-masked]>
Date: Mon, 12 Apr 2004 16:51:58 -0600

Hi Andrew, all, 

Please review the attached with the proposed changes for the StorageType
issues to see of they cover all concerns.

In summary, there are eight proposed changes

Changes 1,2,3,4 are related to the issue brough by Andrew Donati by
adding StorageType object to the Modulation profile table

Changes 5,6,7,8 are clarifications to accommodate the OPS MIB revision
guidelines sections 4.6.2 and 4.6.4, quite related to the problem raised
for the storageType case.

During the WG Last call for technical issues, there were no other items
pointing our attention.

Let the WG know any question or comments by COB Wednesday before
submiting the draft to IETF.

Eduardo

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 13 Apr 2004 11:57:05 -0700

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-masked]>
> To: "Donati Andrew-MGIA0477" <[email-masked]>; <[email-masked]>
> 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

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

---

From: Azlina Ahmad <[email-masked]>
Date: Wed, 14 Apr 2004 13:50:33 -0700

In general, how would we avoid storing a 'bad' configuration?

For example:
      User might create an notInService entry and set the storageType
to nonVolatile (persistent across reload). And while its in Status of 
notInService, the columnar values are not validated.

Change #2:
   :
   "Initial default entries ....., which could report
   for a value 'permanent' or 'readOnly' for docsIfCmtsModStorageType.
   A CMTS may not allow the creation of additional Interval ....."

   [AZ] I found the above to be confusing:
   Can we reword it to:

   "Initial default entries may be created at system intialization
    time by defaulting the docsIfCmtsModStorageType value to
    'permanent(4)' or 'readOnly(5).

Change #3:
   :
   :
   Conceptual rows having the value 'permanent' need
   not allow write-access to any columnar objects ..."

   [AZ] Since the definition of 'permanent(4)' mentioned that
   a row can be changed but not deleted, I don't think we need
   to repeat the statement above.

Thanks,
Azlina