RE: Changes for next RFI v2 MIB (draft 10)
"Eduardo Cardona" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
Hi,
That's a very good detailed analysis for the proposed changes,
Before going to a detail response, RFI MIBv2 is an update of RFC 2670,
V2 introduces in brief :
*DOCSIS 2.0 new burst profiles ( in terms of extensions of existing
enumerations)
*Upstream Channels SCDMA parameters in docsIfUpstreamChannelTable
*Utilization and DOCSIS MAC Counters
docsIfCmtsChannelUtilizationTable,
docsIfCmtsDownChannelCounterTable, docsIfCmtsUpChannelCounterTable
*Added some objects in docsIfCmtsCmStatusTable
The other set of objects related to not DOCSIS 2.0 enhanced
functionality were not updated nor the wording of RFC2670 original
objects in terms of OPS guidelines being leaved as they were in RFC
2670.
Proposed changes are in two categories,
1..4 Modulation Profiles StorageType object
5..8 read-write/read-create objects not upgraded by DOCSIS 2.0 that
could be questioned by IESG in terms of OPS MIB guidelines for not
indicating persistence requirements.
Note that 5..8 all have compliance statements that allows MIN-ACCESS
read-only back in RFC 2670
The disjunctive here is be OPS MIB guidelines compliance without
introduce new requirements or indeed introduce new technical changes
(persistence MUST) not identified before.
Options :
5..8 a) as proposed (explicit vendor specific, not interoperable, with
the precendent of read-only compliances)
b) turn as MUST (new requirement: sent proposal back to IPCDN group
and DOCSIS groups for approval)
c) leave silent as in RFC 2670 (not introduce changes 5..8)
a) or b) will be my options, I started with a) due the b) implications.
See inline some specific comments
-----Original Message-----
From: Randy Presuhn [mailto:[email protected]]
Sent: Tuesday, April 13, 2004 12:57 PM
To: [email protected]
Subject: Re: [ipcdn] 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"
<edo>
Will update all document to upper cases MAY, MUST, MUST NOT
</edo>
> 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"?
<edo>
A bit clear saying :
"A CMTS MAY allow...."
</edo>
...
> Note that some objects do not have default value ,
I think you mean "values"
<edo>
Yes, and may leave as he original RFC 2670 version and previous drafts.
"Note that some objects do not have DEFVALs,"
</edo>
...
> 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
...
<edo>
(a) and (b);
Not sure how (a)is put in context, docsIfCmtsModChannelType is a
Configuration parameter.
An alternative:
1. If a modulation profile is being referenced by one or more
upstream channels, an attempt to set the value of
docsIfCmtsModChannelType returns 'inconsistentValue' error.
2. If a modulation profile is being referenced by one or more
upstream channels, an attempt to set docsIfCmtsModControl
to destroy(6) or notInService(2) returns 'inconsistentValue'
error.
</edo>
> 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.)
<edo>
Agree, Although text current text was discussed discussed in the IPCDN
list
back around October 10 to 15 (eventually closed to experts in the topic)
1. Entries with this object set to active(1) are
extensions of defined physical interfaces in
the interface MIB RFC 2863, entries created by
createAndWait(5) are temporarily created to
clone parameters.
</edo>
> 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???
<edo>
By definition an entry with status active(1) is the extension if IfTable
For interfaces ifType 129 or 205 - regular ifTable extension-
Those are not deleted since are hardware dependant nor created by users,
Only the non-related to ifTable interface entries ( used for clonning)
are created with CreateAndWait and the rules 4 and 5 apply
4. Temporary inactive rows must be created using
createAndWait(5).
5. The only possible status change of a row created using
createAndWait(5) (i.e. notInService(2)) or notReady(3)
is to destroy(6).
</edo>
> 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?
<edo>
Should replaced by SHOULD
No other SNMP mechanism is defined explicitely,
If I understood your request from the possibility of
docsIfUpChannelStatus = notInService(2)
Upstream channels docsIfUpChannelStatus only reports active(1)
</edo>
> 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.
<edo>
Changed for MUST
The current compliance statement is hard to build since the Flavor (US
channel interface vs Cloning entry)
Is the one with different connotation
IfEntry extension read active(1)
No ifEntry extension: CreateAndWait(5), destroy(6) write
For docsIfBasicComplianceV2 MODULE-COMPLIANCE
Current:
OBJECT docsIfUpChannelStatus
MIN-ACCESS read-only
DESCRIPTION
"Read-create in Cable Modem Termination Systems,
read-only in Cable Modems."
Proposed:
OBJECT docsIfUpChannelStatus
SYNTAX RowStatus (active(1), notReady(2))
WRITE-SYNTAX RowStatus (CreateAndGo(5), destroy(6))
MIN-ACCESS read-only
DESCRIPTION
"Read-create in Cable Modem Termination Systems,
read-only in Cable Modems.
Entries associated to upstream channels entries in ifTable
only support read-only value active(2)
Entries used for cloning purposes supports values
notReady(2)
createAndGo(5) and destroy(6)."
</edo>
> 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)
<edo>
Never goes active, created entries are used d only as a buffer
for copying values from an upstream channel, modify them and update
The same or other operational interface.
In RFC 2670 docsIfUpChannelEntries where read-write with optional
read-only ( no row status), just simple extension of IfTable which are
Vendor dependant configured this extension entries are by default
"always"
Active(1)
</edo>
> 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.
<edo>
Item 2 is for the ifTable entries extension (physical upstream channel
entries)
not for the user created entries
Will the proposed text plus the Object compliance makes that a bit
clear?
</edo>
> A Mandatory procedure for adjusting an specific physical Upstream
> channel is:
why is "mandatory" capitalized?
<edo>
Typo, fixed
</edo>
> 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?
<edo>
Out of scope, as the design was concern, you will point with all reasons
that is not
Good for interoperability
Will be a scalar with a suggested initial value an option?
it will goes beyond the closed for additions as we stand rigth now.
</edo>
> 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.
<edo>
I read inconsistenValue as values that in other circumstances will be
valid,
e.g setting to a row while active returns inconsistentValue error but if
the row is set to 'notInService' same set will success (RowStatus
constrains).
Here we had the problem that DOCSIS PHY parameters are broad and some
implementation MAC and or PHY may not support the whole range,
for that cases the vendor should be able do document the
AGENT-CAPABILITIES for the implementation version or model
</edo>
> 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.
<edo>
Will be better to mandate non-persistence?
In any case temporary entries have no operational or configuration
meaning after the cloning process
is completed,
Perhaps:
"Temporary entries SHOULD NOT persist at
reinitialization of the managed system."
</edo>
...
> CHANGE #6
> docsIfQosProfileEntry OBJECT-TYPE
...
> An entry in this table must not be removed while it is
MUST NOT?
<edo>
done
</edo>
> An entry in this table should not be changeable while
SHOULD NOT?
<edo>
done
</edo>
> 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?
<edo>
By the way, old text from RFC2670,
can be updated to say "NOT RECOMMENDED"
<edo>
...
> 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.
<edo>
docsIfDownstreamChannelTable are configuration parameters, if SNMP is
read-only by compliance,
persistente IMHO is not a feature, Either the system uses defaults upon
reboot or the system
gather the parameters from a config file. (which is persistent but
outside the scope of SNMP)
Requiring persisntece now will be a new requirement, for DOCSIS not in
RFC 2670 nor DOCSIS spec.
which should be considered for further work or send back the draft to
IPCDN group discussions for approval.
</edo>
...
> 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.
<edo>
There is no read-create object for this table, it is also a ifTable
extension (for downstream interfaces ifType 128)
</edo>
...
> 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.
<edo>
Same as above, setting persistence requirements will require IPCDN group
to discuss and aprove that.
</edo>
> 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"
<edo>
Ok,
</edo>
> 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.
<edo>
Ok,
queues are deleted and CMs will re-register. Therefore, persistence does
not apply
</edo>
> 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.
<edo>
Will explore that a little bit more
</edo>
...
Randy
_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn