RE: request for ID publication: DOCSIS RFIv2 mib - 2670bis
"Eduardo Cardona" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
IPCDN group participants,
Below is a list of the pending issues raised by Bert and Randy with my
reply, All other comments I believe are addressed in the attached draft
(build against XML2RFC ver 1.28, and checked with levkowetz NITS ver
1.58 and smilint )
see reply emails:
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01582.html
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01583.html
Items NOT listed below still need MIB doctor's "RE:" to the proposed
resolution (marked with ">>" in the emails listed above).
Some of the pending items are editorial to complete prior to submit as
IETF ID 13
Others (normally with *) are calling for MIB Doctors or IPCDN
participants comments.
In any case I do not believe these are technical changes ( to return to
WGLC) and more editorial issues that improve the content itself. -
comments?
Please make the appropriate comments by COB Feb 11 before submitting the
ID.
Thanks
Eduardo
Pending issues for clarification and resolution:
--> Odd case
docsIfCmtsCmStatusTimingOffset,
(*)
>>UNITS "SixtyFourthOfTicks"
--> odd case
docsIfCmtsCmStatusHighResolutionTimingOffset
(*)
>>UNITS "SixtyFourthTwoHundredFiftySixthOfTicks"
Or (16384)
>>UNITS "SixteenThousandsThreeHundredEigthyFourthOfTicks"
all need UNITS clauses
docsIfUpChannelSlotSize - should have UNITS
(*)
>>UNITS "ticks"
>> I believe is not good to use timeticks, which could be confusing with
TC TimeTicks from RFC 2679,
the "DOCSIS" ticks are slots of 6.25 usecs,
see 1) above, the issues of how to name units of ticks/64 or
ticks/(64*256)
docsIfUpChannelTxTimingOffset - should have UNITS
(*)
>>UNITS "SixtyFourthOfTicks"
docsIfUpChannelScdmaActiveCodes - since the primes can never be set and
can never be returned, they should be excluded in the SYNTAX
(*)
>> I am not sure if this is appropiate or will breaks the regular
applications,
To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109,113,127,
the SYNTAX clause will be
SYNTAX Unsigned32
(0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102|104..106|108
|110..112|114..126|128)
Do you prefer this?
How do you break this for the 72 columns ID text file format?
docsIfDownChannelPower: looks like some words got lost
in the update to the DESCRIPTION.
>>
The diff text is:
"May be set to zero at the CM if power level measurement is not
supported."
I believe it was intended to say:
"May report zero at the CM if power level measurement is not supported."
Clearly indicate a DOCSIS 1.0 optional measurement of this parameter.
DOCSIs spec intention was to make that mandatort , therefore removed
since
draft-ietf-ipcdn-docs-rfmibv2-01.txt ( not documented in Changes from
RFC2670 )
(*) Will add the change track
Some of the textual conventions in draft-ietf-ipcdn-docs-rfmibv2-12 need
a little work.
Specifically, The DocsisVersion,
DocsisQosVersion,
DocsisUpstreamType, and
DocsisUpstreamTypeStatus
TCs shouldspecify in their respective DESCRIPTIONS what each of their
enumerated values means.
Randy
>> changed to:
DocsisVersion ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "Indicates the DOCSIS Radio
Frequency specification being
referenced.
'docsis10' indicates DOCSIS 1.0,
'docsis11' indicates DOCSIS 1.1
'docsis20' indicates DOCSIS
2.0"
SYNTAX INTEGER {
docsis10 (1),
docsis11 (2),
docsis20 (3)
}
DocsisQosVersion ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "Indicates the referenced quality of service
level.
'docsis10 refers to DOCSIS 1.0
Class of
Service queuing services.
'docsis11' refers to DOCSIS 1.1
Quality of
Service."
SYNTAX INTEGER {
docsis10 (1),
docsis11 (2)
}
DocsisUpstreamType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "Indicates the DOCSIS Upstream Channel Type.
'unknown' means not information available
or configured to determine.
'tdma' is related to TDMA, Time
Division
Multiple Access, 'atdma' is
related to A-TDMA,
Advanced Time Division Multiple
Access,
'scdma' is related to S-CDMA,
Synchronous
Code Division Multiple Access
'tdmaAndAtdma is related to
simultanous support of
TDMA and A-TDMA modes."
SYNTAX INTEGER {
unknown (0),
tdma (1),
atdma (2),
scdma (3),
tdmaAndAtdma (4)
}
DocsisUpstreamTypeStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates the DOCSIS Upstream Channel Type Status.
Values are the same as DocsisUpstramType but the shared
channel indicator type (tdmaAndAtdma) is not valid, since
this type is used to specifically identify PHY mode."
SYNTAX INTEGER {
unknown (0),
tdma (1),
atdma (2),
scdma (3)
}
>> Your next Q. Why two TC instead of one TC with compliance statements
?
It was for simplicity in the MIB scope of syntax. CMTS can configure
tdmaAndtdma, but CMs uses only one
multiple access method, it means CM status values uses
DocsisUpstreamTypeStatus (DocsisUpstreamType minus tdmaAndAtdma)
and CMTSes uses for configuration DocsisUpstreamType
(*) If recommended compliance statements better, that can be done
==================
Comments with >>
Attached draft for next ID with comments (+ Randy's this week email)
plus a diff file
Eduardo
Bert Wihnen comments:
!! Missing Reference for citation: [RFC2670]
P122 L050: interfaces" [RFC2670].
>> Added in informative reference section (instead of normative
reference section)
5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type
used
in `docsIfCmtsCmStatusEqualizationData'
Probably OK. Can you add some text to explain why this is OK?
>>(*)
I do not have other explanation than "enough" room, probably for
future enhancements (?)
Current DOCSIS MAC may constrain to 256 bytes total the equalizer
data maps.
Does anyone recall the reasons for the number selection?
7. ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type
used in
`docsIfSigQEqualizationData'
you may want to add some text why the range change is OK
>> same as 6.
Other comments:
- docsIfCmtsModControl OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Controls and reflects the status of rows in this table."
::= { docsIfCmtsModulationEntry 3 }
It would be good to add text to explain which (if any) objects can be
changed when the row is active.
Pls check if there are other RowStatus objects that lack that text as
well.
>> Text was on the Entry object
Moved to docsIfCmtsModControl object
There is no restriction on the changing of values in this
table while their associated rows are active with the
exception of:
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."
- WHen you deprecate/obsolete objects or groups or module compliance or
whatever, then it is good practice to ADD a little text to the
DESCRITPION
clause to explain why the depraction/obsoletion occured and which (if
any)
other definition should be used instead.
SYNTAX INTEGER {
other(1),
ranging(2),
rangingAborted(3),
rangingComplete(4),
ipComplete(5),
registrationComplete(6),
accessDenied(7),
operational(8), -- deprecated
registeredBPIInitializing(9)
I do not understand why a "deprecated" value gets added when
upgrading from
RFC2670 to this new document. ??
>>
Two parts:
...
2) (*) Long Story... It was around draft 8 a spec ECR to update the MIB
with value 'complete'
as final value after Cm is in stable mode and registered,
It was found inconvenient to change the final state but few devices were
able to implement
the complete state
Otherwise we need to say in the MIB value 8 -complete is reserved
Alternative : ( not sure if better for IETF process....
docsIfCmtsCmStatusValue OBJECT-TYPE
SYNTAX INTEGER {
other(1),
ranging(2),
rangingAborted(3),
rangingComplete(4),
ipComplete(5),
registrationComplete(6),
accessDenied(7),
-- Enumeration value 8 is reserved
registeredBPIInitializing(9)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Current Cable Modem connectivity state, as specified
in the RF Interface Specification. Returned status
information is the CM status as assumed by the CMTS,
and indicates the following events:
other(1)
Any state other than below.
ranging(2)
The CMTS has received an Initial Ranging Request
message from the CM, and the ranging process is not
yet complete.
rangingAborted(3)
The CMTS has sent a Ranging Abort message to the CM.
rangingComplete(4)
The CMTS has sent a Ranging Complete message to the CM.
ipComplete(5)
The CMTS has received a DHCP reply message and
forwarded it to the CM.
registrationComplete(6)
The CMTS has sent a Registration Response message to
the CM.
accessDenied(7)
The CMTS has sent a Registration Aborted message
to the CM.
registeredBPIInitializing(9)
Baseline Privacy (BPI) is enabled and the CMTS is in the
process of completing BPI initialization. This state
MAY last for a significant length of time if failures
occur during the initialization process. After
completion of BPI initialization, the CMTS will report
registrationComplete(6).
The CMTS only needs to report states it is able to
detect.
Enumeration value 8 is reserved and MUST not be used or
assigned when updating this MIB module"
REFERENCE
"Data-Over-Cable Service Interface Specifications: Radio
Frequency Interface Specification SP-RFIv2.0-I05-040407,
Section 11.2."
::= { docsIfCmtsCmStatusEntry 9 }
>> change to Update:
- The MIB module states:
REVISION "200411221700Z"
DESCRIPTION
"Revision of the IETF RF MIB module for DOCSIS 2.0.
This version published as RFC XXXX."
You need to list (at least the major) changes to the MIB module.
Pls realize that a lot of people extract the MIB module from the
document
and then the sect 10 is not always easily available/handy.
>> will move a quick version of them there. (not yet....)
- Can you explain why you need the compexity of clone from as described
in
docsIfUpChannelCloneFrom, docsIfUpChannelUpdate and
docsIfUpChannelStatus
I really do not understand why you have to make this so complex.
>> We have discussed that in the past, Randy Presuhn was also against
this mechanis
The difference with a clone mechanis as used in USM is that the
clonned entry may
not be turn active ( real physical interface) with hardward
dependencies and ifStack
ramifications hardly described by ifIndex
The clone mechanis copy the values of an active entry into a 'fake
entry'
then parameters are changed and values set back to the ifIndex of
interest.
It helps to minimize service disruption for on service updates.
The group discussed alternatives like a group of scalar objects
mapping the table columns
to do so but it seemed to be at time of design over-defining new set
of objects.
Any intermediate solution (?)
_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn
draft-ietf-ipcdn-docs-rfmibv2-13.txt
(text/plain, 294.6 KB) - not displayed