RE: draft-ietf-hubmib-efm-epon-mib-01.txt
"Lior khermosh" <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
Dan,
Thank you very much for the review and the comments. They are very
helpful.
> T1.
Thanks, will be fixed. One of the reasons to the strange fonts is a
difference in the file in the web. This font will be removed.
> T2. The document does not take a clear position about required changes
from the MAU MIB. As wit the efm-cu document, my preference would be
that we change the MAU MIB structure so that it is re-written as a
IANA-maintained module, but we need a volunteer to do this.
Sorry for being not clear but my intention is that MAU type objects in
the MAU section should be added to the MAUMIBs as with the efm-cu
document. If it is not done there then the MAU section in the efm-epon
mib should contain them (as now).
> T3. Clarify how are dot3MpcpID numbers assigned
dot3MPCPID is referenced to IEEE802.3ah aMPCPID attribute. It is a
read-only attribute for the MIB object.
> T4. Is dot3MpcpAdminState an admin state object as the name suggests,
or an oper state object as the read-only MAX-ACCESS and the DESCRIPTION
clause suggests? Same about dot3MPCPAdminControl
dot3MpcpAdminState is an oper state object and can only be read as the
MAX-ACCESS and description suggest. dot3MPCPAdminControl is for changing
the former state and has a read-write MAX-ACCESS. We can modify the
names to make it more clear, however I would rather stay very close to
the names which are used in the IEEE802.3ah clause 30.
> T5. According to the DESCRIPTION dot3MpcpMaximumPendingGrants should
be in range (0..255)
Agreed and will be added.
> T6. Some of the objects in the dot3MpcpStatsTable seem to be mandatory
just for ONUs? What does an OLT which does not support the counter do?
Maybe the table should be broken into two tables. In any case the
Conformance clauses should reflect the optional support for some of the
counters.
I also saw the problem but I want to be aligned with the IEEE802.3ah
clause 30 which does not implement such separation. We may add in, that
the states which are dedicated to the OLT and ONU can return 0 (and the
opposite).
> T7. dot3OmpEmulationStatTable has objects mandatory for OLT and
optional for ONU. This should be reflected in the conformance cases, and
maybe the table should be broken in separate tables accordingly
I also saw the problem but I want to be aligned with the IEEE802.3ah
clause 30 which does not implement such separation. We may add in that
the stats which are dedicated to the OLT and ONU can return 0 (and the
opposite).
> T8. Clarify what is being returned on a read operation for
eponDeviceObjectReset
When the value is running(0) the device is ready for operation/during
normal operation. and when the value is reset(1) the device is in reset
sequence and not ready for operation. I would add the read values
explanations into the description.
> T9. It is not clear what values are allowed for write for the object
eponDeviceObjectReportThreshold. what does the reference to '2 octets
increments' mean?
As referenced to the IEEE802.3ah the reports message values are in Time
quanta which are equivalent to 16nsec or 2 bytes/octets. I will clarify
that in the text.
> T10. Are values in eponDeviceRemoteMACAddressLLIDTable persitent, or
can they be erased on a reset?
Thanks for your suggestion. I must agree that they could also be erased
on a reset. I will add to the text.
> T11. The DESCRIPTION of the eponDeviceRemoteMACAddressLLIDTable is
very unclear - I did not understand how this works
I will clarify the text. The purpose of this table is to hold an LLID to
MAC address table. This mapping is needed for the EPON network emulation
as a bridge where its LLID is acting as a bridge port.
> T12. What does the object eponDeviceRMadLogID with a SYNTAX of OBJECT
IDENTIFIER point to?
Should be eponDeviceRMadlLogID. This object creates an entry in the LLID
MAC address table.
> T13. The design of the eponDeviceEventsLogTable is not clear. What
notifications are being referred by this table? Why does this need to be
a dynamic row creation table?
The table intention is to create and store a log of events. The types of
events are defined by:
eponDeviceEventsLogType:
eponDeviceDyingGaspAlarmState (1),
eponDeviceCriticalEventState (2),
eponDeviceLocalLinkFaultAlarmState (3),
eponDeviceTemperatureEventIndicationState (4),
eponDevicePowerVoltageEventIndicationState (5),
eponDeviceGlobalEventState (6),
eponDeviceErroredSymbolPeriodEventState (7),
eponDeviceErroredFrameEventState (8),
eponDeviceErroredFramePeriodEventState (9),
eponDeviceErroredFrameSecondsSummaryEventState (10),
eponDeviceOrganizationSpecificEventState (11)
Entries in the table are created dynamically once events happens. When
event happens it receives the following parameters.:
eponDeviceEventsLogName ,
eponDeviceEventsLogIndex ,
eponDeviceEventsLogID ,
eponDeviceEventsLogFirstTime ,
eponDeviceEventsLogLastTime ,
eponDeviceEventsLogCounts ,
eponDeviceEventsLogType ,
eponDeviceEventsLogEntryStatus
> T14. The security section claims that most objects are writeable when
the link is down. First there is a need to clarify what exactly is meant
by the link is down (ifAdminStatus = off(2)? for what ifIndex value?).
Second, this restriction needs to be mentioned for every specific
objects in the MIB module itself (DESCRIPTION clauses) and not left in
an external section.
Agree - can't use "most" here. I will add specification for each
attribute and specify the state of the change for it.
> T15. Why define a eponDeviceSerialNumber, and not use
entPhysicalSerialNumber from the Entity MIB? (RFC 2737, or
<http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-entmib-v3-
04.txt>
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-entmib-v3-0
4.txt)
I agree, we can use it.
Editorial
Thanks, will be fixed. A few remarks in the text.
> E1. The Internet-Draft has awful formatting errors. Please follow the
guidelines at <http://www.ietf.org/ietf/1id-guidelines.txt>
http://www.ietf.org/ietf/1id-guidelines.txt.
> E2. Among these formatting errors, one very obvious, with effects on
compilation of the MIB modules as well is the use of illegal characters.
> E3. There is a new Intellectual Property Template that needs to be
used. See the same reference.
> E4. An IANA Consideration section needs to be added
> E5. Copyright year needs to be updated to 2004.
> E6. There are many spelling and syntax errors, that make the text
sometimes impossible to understand. In fact there are that many that I
will not list them all here, but rather forward a scribbled hardcopy to
the editors with hand-written markings.
> E7. All over the document - say 'MIB module' instead of MIB when
referring to the module, and not a specific MIB, and 'MIB modules'
instead of 'MIBs'
> E8. DESCRIPTION clause of dot3MpcpTable - expand MPCP at the first
occurrence of the acronyms
> E9. There are many DEFVAL clauses missing for read-write or
read-create objects. For example: dot3MpcpMode, dot3EponMauFecMode,
eponDeviceObjectModes, eponDeviceObjectFecEnabled,
eponDeviceObjectOamMode, eponDeviceRMadLogID,
eponDeviceRMadRemoteMacAddress, eponDeviceRMadType,
eponDeviceRMadAction, eponDeviceSampleMinimum,
> E10. There are many UNITS clauses missing. For example:
dot3MpcpTransmitElapsed, all counters in dot3MpcpStatsTable, all
counters in dot3OmpEmulationStatTable, counters in dot3EponMauTable,
counters in eponDeviceStatsTable
> E11. dot3OmpEmulationID DESCRIPTION includes reference to an IEEE
object.
I know. I think it is an error in the text of the IEEE802.3ah. I marked
it to myself and did not change it automatically to dot3OmpEmulationID
as to figure this issue out. If I change it we are not aligned with the
IEEE. I would rather see here a different ID than the OAMID (for the
EFM-MIB document I guess) since it is different. Any suggestion?
> E12. I recommend that the tables that map the MIB objects defined in
this document into IEEE 802.3 objects be separated from the MIB objects
definition section.
I don't understand the comment It has a separate section:
4 Definitions - The EFM EPON MIB
6
5 Relationship table of the EFM EPON MIBs objects to the IEEE802.3ah
objects 32
6 Definitions - The EPON Device MIB
34
> E13. All enumerated and BITS values need to be explained in
DESCRIPTION. E.g. 'A value of olt(1) means...' - Foe example in
eponDeviceObjectModes, eponDeviceObjectFecEnabled,
eponDeviceObjectOamMode,
> E14. eponDeviceObjectPowerDown should refer to value true(1)
> E15. The significance of the events defined by the enumerated values
of eponDeviceEventsLogTable needs to be expanded
> E16. Why are DOCSIS MIB, Event MIB, Bridge MIB and Source Routing
Bridge MIB referenced?
In the document the methodology and formatting are used. It is not a
direct reference rather a "styling" reference.
Lior
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Romascanu, Dan (Dan)
Sent: Sunday, August 01, 2004 1:06 PM
To: [email protected]
Subject: [Hubmib] draft-ietf-hubmib-efm-epon-mib-01.txt
Technical
T1. None of the two MIB modules compiles correctly. While the first MIB
modules warnings are caused by illegal characters in the DESCRIPTION
clauses, the EPON Device MIB has 'true compilation errors. Here is the
smilint log for these:
This command (smilint 0.4.3-pre1, as of Tue Jul 27 14:25:07 2004)
has been processed to get the following results:
smilint -m -s -m -s -l 6 -i namelength-32 epon-device-mib.txt
...
epon-device-mib.txt:230: [5] {integer-misuse} warning: use Integer32
instead of INTEGER in SMIv2
epon-device-mib.txt:230: [2] {access-invalid-smiv2} invalid access
`read-Only' in SMIv2 MIB
epon-device-mib.txt:329: [1] {other} parse error, unexpected '}',
expecting LOWERCASE_IDENTIFIER
epon-device-mib.txt:329: [5] {} warning: flushing recent incorrect
declaration, see previous error(s)
epon-device-mib.txt:330: [1] {other} parse error, unexpected MAX_ACCESS
epon-device-mib.txt:334: [5] {} warning: flushing recent incorrect
declaration, see previous error(s)
epon-device-mib.txt:341: [1] {other} parse error, unexpected '}',
expecting ')'
epon-device-mib.txt:341: [5] {} warning: flushing recent incorrect
declaration, see previous error(s)
epon-device-mib.txt:342: [1] {other} parse error, unexpected MAX_ACCESS
epon-device-mib.txt:346: [5] {} warning: flushing recent incorrect
declaration, see previous error(s)
...
epon-device-mib.txt:115: [3] {sequence-no-column} SEQUENCE element #9
`eponDeviceObjectRemoteMACAddressLLIDTable' is not a child node under
`eponDeviceControlEntry'
epon-device-mib.txt:115: [3] {sequence-no-column} SEQUENCE element #10
`eponDeviceObjectReportThreshold' is not a child node under
`eponDeviceControlEntry'
epon-device-mib.txt:125: [1] {} unknown object identifier label
`eponDeviceObjectRemoteMACAddressLLIDTable'
epon-device-mib.txt:278: [3] {sequence-no-column} SEQUENCE element #4
`eponDeviceRMadlRemoteMACAddress' is not a child node under
`eponDeviceRemoteMACAddressLLIDEntry'
epon-device-mib.txt:278: [3] {sequence-no-column} SEQUENCE element #5
`eponDeviceRMadlType' is not a child node under
`eponDeviceRemoteMACAddressLLIDEntry'
epon-device-mib.txt:278: [3] {sequence-no-column} SEQUENCE element #6
`eponDeviceRMadlAction' is not a child node under
`eponDeviceRemoteMACAddressLLIDEntry'
epon-device-mib.txt:278: [3] {sequence-missing-column} SEQUENCE of
`EponDeviceRemoteMACAddressLLIDEntry' is missing columnar object
`eponDeviceRMadlRemoteMacAddress'
epon-device-mib.txt:266: [5] {index-element-accessible} warning: index
element `eponDeviceRMadlLLID' of row
`eponDeviceRemoteMACAddressLLIDEntry' should be not-accessible in SMIv2
MIB
epon-device-mib.txt:282: [1] {} unknown object identifier label
`eponDeviceRMadlRemoteMACAddress'
epon-device-mib.txt:283: [1] {} unknown object identifier label
`eponDeviceRMadlType'
epon-device-mib.txt:284: [1] {} unknown object identifier label
`eponDeviceRMadlAction'
epon-device-mib.txt:1218: [3] {group-member-invalid} node
`eponDeviceRMadlLogName' is an invalid member of group
`eponDeviceGroupRMadLTable'
epon-device-mib.txt:316: [4] {group-membership} warning: node
`eponDeviceRMadlRemoteMacAddress' must be contained in at least one
conformance group
T2. The document does not take a clear position about required changes
from the MAU MIB. As wit the efm-cu document, my preference would be
that we change the MAU MIB structure so that it is re-written as a
IANA-maintained module, but we need a volunteer to do this.
T3. Clarify how are dot3MpcpID numbers assigned
T4. Is dot3MpcpAdminState an admin state object as the name suggests, or
an oper state object as the read-only MAX-ACCESS and the DESCRIPTION
clause suggests? Same about dot3MPCPAdminControl
T5. According to the DESCRIPTION dot3MpcpMaximumPendingGrants should be
in range (0..255)
T6. Some of the objects in the dot3MpcpStatsTable seem to be mandatory
just for ONUs? What does an OLT which does not support the counter do?
Maybe the table should be broken into two tables. In any case the
Conformance clauses should reflect the optional support for some of the
counters.
T7. dot3OmpEmulationStatTable has objects mandatory for OLT and optional
for ONU. This should be reflected in the conformance cases, and maybe
the table should be broken in separate tables accordingly
T8. Clarify what is being returned on a read operation for
eponDeviceObjectReset
T9. It is not clear what values are allowed for write for the object
eponDeviceObjectReportThreshold. what does the reference to '2 octets
increments' mean?
T10. Are values in eponDeviceRemoteMACAddressLLIDTable persitent, or can
they be erased on a reset?
T11. The DESCRIPTION of the eponDeviceRemoteMACAddressLLIDTable is very
unclear - I did not understand how this works
T12. What does the object eponDeviceRMadLogID with a SYNTAX of OBJECT
IDENTIFIER point to?
T13. The design of the eponDeviceEventsLogTable is not clear. What
notifications are being referred by this table? Why does this need to be
a dynamic row creation table?
T14. The security section claims that most objects are writeable when
the link is down. First there is a need to clarify what exactly is meant
by the link is down (ifAdminStatus = off(2)? for what ifIndex value?).
Second, this restriction needs to be mentioned for every specific
objects in the MIB module itself (DESCRIPTION clauses) and not left in
an external section.
T15. Why define a eponDeviceSerialNumber, and not use
entPhysicalSerialNumber from the Entity MIB? (RFC 2737, or
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-entmib-v3-0
4.txt)
Editorial
E1. The Internet-Draft has awful formatting errors. Please follow the
guidelines at http://www.ietf.org/ietf/1id-guidelines.txt.
E2. Among these formatting errors, one very obvious, with effects on
compilation of the MIB modules as well is the use of illegal characters.
E3. There is a new Intellectual Property Template that needs to be used.
See the same reference.
E4. An IANA Consideration section needs to be added
E5. Copyright year needs to be updated to 2004.
E6. There are many spelling and syntax errors, that make the text
sometimes impossible to understand. In fact there are that many that I
will not list them all here, but rather forward a scribbled hardcopy to
the editors with hand-written markings.
E7. All over the document - say 'MIB module' instead of MIB when
referring to the module, and not a specific MIB, and 'MIB modules'
instead of 'MIBs'
E8. DESCRIPTION clause of dot3MpcpTable - expand MPCP at the first
occurrence of the acronyms
E9. There are many DEFVAL clauses missing for read-write or read-create
objects. For example: dot3MpcpMode, dot3EponMauFecMode,
eponDeviceObjectModes, eponDeviceObjectFecEnabled,
eponDeviceObjectOamMode, eponDeviceRMadLogID,
eponDeviceRMadRemoteMacAddress, eponDeviceRMadType,
eponDeviceRMadAction, eponDeviceSampleMinimum,
E10. There are many UNITS clauses missing. For example:
dot3MpcpTransmitElapsed, all counters in dot3MpcpStatsTable, all
counters in dot3OmpEmulationStatTable, counters in dot3EponMauTable,
counters in eponDeviceStatsTable
E11. dot3OmpEmulationID DESCRIPTION includes reference to an IEEE
object.
E12. I recommend that the tables that map the MIB objects defined in
this document into IEEE 802.3 objects be separated from the MIB objects
definition section.
E13. All enumerated and BITS values need to be explained in DESCRIPTION.
E.g. 'A value of olt(1) means...' - Foe example in
eponDeviceObjectModes, eponDeviceObjectFecEnabled,
eponDeviceObjectOamMode,
E14. eponDeviceObjectPowerDown should refer to value true(1)
E15. The significance of the events defined by the enumerated values of
eponDeviceEventsLogTable needs to be expanded
E16. Why are DOCSIS MIB, Event MIB, Bridge MIB and Source Routing Bridge
MIB referenced?
Regards,
Dan
_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib