RFC Errata
Found 25 records.
Status: Verified (6)
RFC 5601, "Pseudowire (PW) Management Information Base (MIB)", July 2009
Source of RFC: pwe3 (int)
Errata ID: 4069
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2014-08-05
Verifier Name: Brian Haberman
Date Verified: 2014-08-06
Section 12 says:
pwAttachedPwIndex OBJECT-TYPE
SYNTAX PwIndexOrZeroType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If the PW is attached to another PW instead of a local
native service, this item indicates the pwIndex of the
attached PW. Otherwise, this object MUST
be set to zero. Attachment to another PW will have no
PW specific entry in any of the service MIB modules."
DEFVAL { 0 }
::= { pwEntry 10 }
It should say:
pwAttachedPwIndex OBJECT-TYPE
SYNTAX PwIndexOrZeroType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If the PW is attached to another PW instead of a local
native service, this item indicates the pwIndex of the
attached PW. Otherwise, this object MUST
be set to zero. Attachment to another PW will have no
PW specific entry in any of the service MIB modules.
This object may be modified only when the value of
the associated pwAdminStatus object is down(2), and
the associated pwOperStatus object has value down(2)
or notPresent(5) such that the row in the pwTable
represents an inactive PW."
DEFVAL { 0 }
::= { pwEntry 10 }
Notes:
Description of the pwEntry object in the same RFC states that "The read-create objects in this table are divided into
three categories:
1) Objects that MUST NOT be changed after row activation.
These are objects that define basic properties of the
PW (for example type, destination, etc.).
2) Objects that MAY be changed when the PW is
defined as not active. A change of these objects involves
re-signaling of the PW or it might be traffic affecting.
PW not active is defined as one of the following
conditions:
a) The pwRowStatus is notInService(2).
b) The pwRowStatus is notReady(3).
c) The pwAdminStatus is down(2).
If the operator needs to change one of the values for an
active row, the operator can either set the pwRowStatus to
notInService(2) or set pwAdminStatus to down(2).
Signaling (or traffic) is initiated again upon setting
the pwRowStatus to active(1) or setting the pwAdminStatus
to up(1) or testing(3), respectively.
3) Objects that MAY be changed at any time."
In further states (in tthe same description) that "By default, all the read-create objects MUST NOT be changed after row activation, unless specifically indicated in the individual object description."
pwAttachedPwIndex object is used to stitch a couple of PWs represented by two different rows in the pwTable, with the pwAttachedPwIndex value in the row representing one of them set to the pwIndex of the other one and vice versa.
Since there is no way in the SMIv2 paradigm to create two rows in the same table
in a single atomic operation, setting a this attribute in a pair of rows is only
possible when both are created. In order to do that, read-create access mode of
the pwAttachedPwIndex object has to be interpreted as ability to set its value
when the row represents an inactive PW.
In accordance with the quoted description, such an interpretation must be
explicitly specified in the description of this object.
Such a specification is missing in the current text, hence the default
interpretation of the read-create access mode is holds.
Proposed text fixes this problem.
Errata ID: 1859
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Verifier Name: Stewart Bryant
Date Verified: 2011-11-12
Section 12, pg.25 says:
[[ DESCRIPTION clause for pwFcsRetentionCfg OBJECT-TYPE ]]
"The local configuration of Frame Check Sequence (FCS)
retention for this PW. FCS retention can be configured for
PW types High-Level Data Link Control (HDLC), Point-to-Point
Protocol (PPP), and Ethernet only. If the implementation
| does not support FCS retention, an error MUST be reported in
pwFcsRetentionStatus. This object MAY be changed only if
the PW is not active."
It should say:
"The local configuration of Frame Check Sequence (FCS)
retention for this PW. FCS retention can be configured for
PW types High-Level Data Link Control (HDLC), Point-to-Point
Protocol (PPP), and Ethernet only. If this object is set to
fcsRetentionEnable(2) and the implementation does not support
the FCS retention for this PW, an error MUST be indicated by
setting pwFcsRetentionStatus to localFcsRetentionCfgErr(4).
This object can be changed only if the PW is not active."
Notes:
Rationale:
The original DESCRIPTION indicated unconditional signaling of an error, whether
the activation of unsupported FCS retention is requested or not.
This is contrary to the DESCRIPTION for pwFcsRetentionStatus.
Errata ID: 3030
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stewart Bryant
Date Reported: 2011-11-12
Verifier Name: Stewart Bryant
Date Verified: 2011-11-12
Section 12, page 37 says:
pwPerf1DayIntervalTable OBJECT-TYPE
SYNTAX SEQUENCE OF PwPerf1DayIntervalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides per-PW performance information for
the current day's measurement and the previous day's
interval."
It should say:
DESCRIPTION
"This table provides per-PW performance information for
the current day's measurement and the previous day's
measurement."
Errata ID: 1861
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Verifier Name: Stewart Bryant
Date Verified: 2011-11-12
Section 12, pg.34 says:
pwPerfIntervalEntry OBJECT-TYPE
SYNTAX PwPerfIntervalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table is created by the agent for every
| PW."
It should say:
pwPerfIntervalEntry OBJECT-TYPE
SYNTAX PwPerfIntervalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table is created by the agent for every
monitored interval for each monitored PW."
Errata ID: 1862
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Verifier Name: Stewart Bryant
Date Verified: 2011-11-12
Section 12, pg.38 says:
pwPerf1DayIntervalEntry OBJECT-TYPE
SYNTAX PwPerf1DayIntervalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table is created by the agent for every
| PW."
It should say:
pwPerf1DayIntervalEntry OBJECT-TYPE
SYNTAX PwPerf1DayIntervalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table is created by the agent for every
monitored day for each monitored PW."
Errata ID: 2815
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Cohn
Date Reported: 2011-05-24
Verifier Name: Stewart Bryant
Date Verified: 2011-11-12
Section Daniel says:
pwOperStatus OBJECT-TYPE
SYNTAX PwOperStatusTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the operational status of the PW; it
does not reflect the status of the Customer Edge (CE) bound
interface. It is set to down only if pwNotForwarding,
psnFacingPwRxFault, or psnFacingPwTxFault indications are
set in pwLocalStatus or pwRemoteStatus.
It indicates 'lowerLayerDown' if the only reason for
not being in the 'up' state is that either the outer tunnel
or physical layer of the network side is in the 'down'
state.
All other states are declared based on the description
of the PwOperStatusTC.
"
::= { pwEntry 38 }
It should say:
pwOperStatus OBJECT-TYPE
SYNTAX PwOperStatusTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the operational status of the PW; it
does not reflect the status of the Customer Edge (CE) bound
interface. It is set to down only if pwNotForwarding,
psnPwRxFault, or psnPwTxFault indications are
set in pwLocalStatus or pwRemoteStatus.
It indicates 'lowerLayerDown' if the only reason for
not being in the 'up' state is that either the outer tunnel
or physical layer of the network side is in the 'down'
state.
All other states are declared based on the description
of the PwOperStatusTC.
"
::= { pwEntry 38 }
Notes:
psnFacingPwRxFault and psnFacingPwTxFault were replaced in RFC 5542 by psnPwRxFault and psnPwTxFault respectively
Status: Held for Document Update (13)
RFC 5601, "Pseudowire (PW) Management Information Base (MIB)", July 2009
Source of RFC: pwe3 (int)
Errata ID: 1856
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-08
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12
Section 12, pg.18 says:
pwPeerAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Denotes the address type of the peer node. It should be
set to 'unknown' if PE/PW maintenance protocol is not used
and the address is unknown."
DEFVAL { ipv4 }
::= { pwEntry 8 }
pwPeerAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object contains the value of the peer node address
of the PW/PE maintenance protocol entity. This object
SHOULD contain a value of all zeroes if not applicable
(pwPeerAddrType is 'unknown')."
::= { pwEntry 9 }
It should say:
pwPeerAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
| "Denotes the address type of the peer node stored in
| pwPeerAddr. It should be set to 'unknown' if PE/PW
maintenance protocol is not used and the address is
unknown."
DEFVAL { ipv4 }
::= { pwEntry 8 }
pwPeerAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object contains the value of the peer node address
| of the PW/PE maintenance protocol entity. The type of this
| object is determined by the corresponding pwPeerAddr object.
| This object MUST contain a zero-length octet string if not
applicable (pwPeerAddrType is 'unknown')."
::= { pwEntry 9 }
Notes:
Rationale:
a) RFC 4001 requests that every use of InetAddressType and
InetAddress makes explicit the coupling between the objects.
Hence, the DESCRIPTION clause(s) need to be amended.
For clarity, the Corrected text does so for both objects.
b) RFC 4001 (pg. 6) specifies that an InetAddressType object of
value unknown(0) correspond to an InetAddress object
that is a zero-length string, unless unknown(0) is used to
indicate an internet address type not (yet) known (at the time
of publication of RFC 4001). All Standards Track MIB modules
making use of InetAddressType so far couple the value unknown(0)
with an InetAddress of size 0, because an unknown IP address
of a (known) specific type can be represented by the
"unspecified address" of that address format.
Hence, the original text should be changed.
This has been done in the perceived spirit of the conformance
specification for pwPeerAddr on mid-page 51 and page 54.
This is a correct, however, it is unlikely that "unknown" is ever used in an implementation. Therefore it is not critical to fix this, hence classifying as hold for document update.
Errata ID: 1852
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-08
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12
Section 12, pg.27 says:
pwLastChange OBJECT-TYPE
| SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time the PW entered
its current operational state. If the current state was
entered prior to the last re-initialization of the local
network management subsystem, then this object contains a
zero value."
::= { pwEntry 36 }
It should say:
pwLastChange OBJECT-TYPE
| SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time the PW entered
its current operational state. If the current state was
entered prior to the last re-initialization of the local
network management subsystem, then this object contains a
zero value."
::= { pwEntry 36 }
Notes:
[[ Location is bottom of page 27 ]]
Like any other object intended to keep a snapshot of sysUpTime,
this object must have the corrresponding SYNTAX of TimeStamp
(cf. pwCreateTime, on mid-page 27); a SYNTAX of TimeTicks is
appropriate on;y for 'running clocks' started at a particular
event (like pwUpTime, also on pg. 27, just above pwLastChange).
Although technically correct that the SYNTAX should be TimeStamp, this
is safe because the SYNTAX of TimeStamp is TimeTicks.
Errata ID: 1853
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-08
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12
Section 11, 1st para says:
This section contains the initial version of the IANA-PWE3-MIB. IANA | has updated this MIB module based on expert review as defined in [RFC5226]. Each new assignment of PW type or PW PSN type made by IANA based on the procedures described in [RFC4446] should be documented in the online version of IANA-PWE3-MIB. The current IANA-PWE3-MIB contains PW types as requested in [RFC4446] and [RFC4863].
It should say:
This section contains the initial version of the IANA-PWE3-MIB. IANA | will update this MIB module based on expert review as defined in [RFC5226]. Each new assignment of PW type or PW PSN type made by IANA based on the procedures described in [RFC4446] should be documented in the online version of IANA-PWE3-MIB. The current IANA-PWE3-MIB contains PW types as requested in [RFC4446] and [RFC4863].
Notes:
Wrong temporal relationship!
Errata ID: 1854
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-08
Held for Document Update by: Stewart Bryant
Section 11, pg. 8 says:
[[ 2nd para of DESCRIPTION clause for ianaPwe3MIB MODULE-IDENTITY ]]
... The
Designated Expert will be selected by the IESG Area
| Director(s) of the internet Area.
^
It should say:
... The
Designated Expert will be selected by the IESG Area
| Director(s) of the Internet Area.
^
Errata ID: 1855
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-08
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12
Section 12, pg.17 says:
[[ 3rd para of DESCRIPTION clause of pw Owner OBJECT-TYPE ]]
'genFecSignaling' is used in case of LDP signaling with
| the generalized FEC.
It should say:
'genFecSignaling' is used in case of LDP signaling with
| the generalized FEC element.
Notes:
This is correct, but is thought unlikely to cause any problems
Errata ID: 1857
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Section 12, pg.19 says:
[[ DESCRIPTION clause of pwAttachedPwIndex OBJECT-TYPE ]]
DESCRIPTION
"If the PW is attached to another PW instead of a local
native service, this item indicates the pwIndex of the
attached PW. Otherwise, this object MUST
| be set to zero. Attachment to another PW will have no
PW specific entry in any of the service MIB modules."
It should say:
DESCRIPTION
"If the PW is attached to another PW instead of a local
native service, this item indicates the pwIndex of the
attached PW. Otherwise, this object MUST
| be set to zero. A PW attached to another PW will have no
PW specific entry in any of the service MIB modules."
Notes:
Rationale: Clarity of language.
Errata ID: 1863
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12
Section 12, pg. 40 says:
[[ DESCRIPTION clause for pwIndexMappingTable OBJECT-TYPE: ]]
"This table enables the reverse mapping of the unique
PWid parameters [peer IP, PW type, and PW ID] and the
pwIndex. The table is not applicable for PWs created
| manually or by using the generalized FEC."
It should say:
"This table enables the reverse mapping of the unique
PWid parameters [peer IP, PW type, and PW ID] and the
pwIndex. The table is not applicable for PWs created
| manually or by using the generalized FEC element."
Notes:
Rationale: Added precision (cf. EID=1855).
Errata ID: 1865
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12
Section 12, pg.41 says:
pwIndexMappingPeerAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
| "IP address of the peer node."
::= { pwIndexMappingEntry 4 }
It should say:
pwIndexMappingPeerAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
| "IP address of the peer node. The type of this object
is determined by the value of the corresponding
pwIndexMappingPeerAddrType object."
::= { pwIndexMappingEntry 4 }
Notes:
Rationale: cf. EID=1856
Errata ID: 1867
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12
Section 12, pg.43 says:
[[ DESCRIPTION clause for pwPeerMappingPeerAddr OBJECT-TYPE: ]] | "IP address of the peer node."
It should say:
| "IP address of the peer node. The type of this object
is determined by the value of the corresponding
pwPeerMappingPeerAddrType object."
Notes:
Rationale: cf. EID=1856 and EID=1865.
Errata ID: 1868
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Section 12, pg.43 says:
[[ REFERENCE clause of pwUpDownNotifEnable OBJECT-TYPE: ]]
"See also [RFC3413] for explanation that
notifications are under the ultimate control of the
| MIB module in this document."
It should say:
"See also [RFC3413] for explanation that
notifications are under the ultimate control of the
| MIB module in that document."
Notes:
Rationale: "this" in the given context is likely to be understood
as pointing to "this" RFC, RFC 5601!
Errata ID: 1869
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Section 12, pg.44 says:
pwDeletedNotifEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If this object is set to true(1), then it enables the
| emission of pwDeleted notification; otherwise, this
notification is not emitted."
REFERENCE
"See also [RFC3413] for explanation that
notifications are under the ultimate control of the
| MIB module in this document."
It should say:
pwDeletedNotifEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If this object is set to true(1), then it enables the
| emission of pwDeleted notifications; otherwise, this
notification is not emitted."
REFERENCE
"See also [RFC3413] for explanation that
notifications are under the ultimate control of the
| MIB module in that document."
Notes:
Rationale:
a) plural is needed;
b) as for EID=1868
Errata ID: 1870
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Section 12, pg.44 says:
[[ DESCRIPTION clause for pwGenFecIndexMappingTable OBJECT-TYPE: ]]
"This table enables the reverse mapping of the unique
PWid parameters [GroupAttachmentID, LocalAttachmentID,
and PeerAttachmentID] and the pwIndex. The table is
| only applicable for PW using the generalized FEC."
It should say:
"This table enables the reverse mapping of the unique
PWid parameters [GroupAttachmentID, LocalAttachmentID,
and PeerAttachmentID] and the pwIndex. The table is
| only applicable for PWs using the generalized FEC."
Notes:
Rationale: plural is needed!
Note:
Surprisingly, the whole definition of the Gen Fec PW ID mapping table
(starting with this entry and extending down to the top of page 47)
is not contained in the part of the MIB module enclosed in comments
'Reverse mapping tables' / 'End of reverse mapping tables'
(extending from top of page 40 to mid-page 43).
It would have been better to move the specification of this table
into that part as well, i.e. to its end -- irrespective of the OID
value assigned to the pwGenFecIndexMappingTable object.
Errata ID: 1873
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Section 12, pg.51 says:
[[ on mid-pg. 51: ]]
OBJECT pwPeerAddr
SYNTAX InetAddress (SIZE(0|4))
DESCRIPTION "An implementation is only required to support
| 0, 4 address sizes."
It should say:
OBJECT pwPeerAddr
SYNTAX InetAddress (SIZE(0|4))
DESCRIPTION "An implementation is only required to support
| address sizes 0 and 4."
Notes:
Rationale:
Grammar: "4 address sizes" has quite different semantics than
"address size 4" !
Note:
This issue recurs on page 54, and a similar correction applies there.
Status: Rejected (6)
RFC 5601, "Pseudowire (PW) Management Information Base (MIB)", July 2009
Source of RFC: pwe3 (int)
Errata ID: 1860
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2011-11-12
Section 12, pg.26 says:
a) [[ 2nd para of DESCRIPTION clause for pwOutboundLabel OBJECT-TYPE: ]]
For MPLS, MPLS over IP, or MPLS over Generic Routing
Encapsulation (GRE) PSN, it represents the 20-bit PW tag;
for L2TP, it represents the 32-bit Session ID; and for
| IP PSN, it represents the destination UDP port number.
b) [[ 2nd para of DESCRIPTION clause for pwInboundLabel OBJECT-TYPE: ]]
For MPLS, MPLS over IP, or MPLS over GRE PSN, it represents
the 20-bit PW tag; for L2TP, it represents the 32-bit
| Session ID; and for IP PSN, it represents the source
UDP port number.
It should say:
a)
For MPLS, MPLS over IP, or MPLS over Generic Routing
Encapsulation (GRE) PSN, it represents the 20-bit PW tag;
for L2TP, it represents the 32-bit Session ID; and for
| IP PSN, it represents the remote UDP port number.
b)
For MPLS, MPLS over IP, or MPLS over GRE PSN, it represents
the 20-bit PW tag; for L2TP, it represents the 32-bit
| Session ID; and for IP PSN, it represents the local
UDP port number.
Notes:
Rationale:
Confusion of terms; the role of source vs. destination port number
changes with the direction in which the packets are sent, whereas
the role of local vs. remote port number is static (from the point
of view of each peer) and as such can be configured here.
The necessary clarification substitutes the proper terms for the
inappropriate ones.
--VERIFIER NOTES--
The original text is clear and correct.
Errata ID: 1864
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2012-02-21
Section 12, pg.40 says:
[[ 2nd para of DESCRIPTION clause for pwIndexMappingEntry OBJECT-TYPE: ]]
Implementers need to be aware that if the value of
| the pwIndexMappingPeerAddr (an OID) has more than
| 113 sub-identifiers, then OIDs of column instances
in this table will have more than 128 sub-identifiers
and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."
It should say:
Implementers need to be aware that if the value of
| the pwIndexMappingPeerAddr corresponds to more than
| 113 sub-identifiers, then OIDs of column instances
in this table will have more than 128 sub-identifiers
and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."
Notes:
Rationale: Clarification of potentially misleading text:
pwIndexMappingPeerAddr is *not* an OID by itself, it is
transformed into an OID when used as an index in the SMI.
An alternate replacement text might be:
Implementers need to be aware that if the value of
| the pwIndexMappingPeerAddr has a size of more than
| 112 octets, then OIDs of column instances
in this table will have more than 128 sub-identifiers
and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."
--VERIFIER NOTES--
The original text is correct and easily understood by a MIB experts.
Errata ID: 1866
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2012-02-21
Section 12, pg.42 says:
[[ 2nd para of DESCRIPTION clause for pwPeerMappingEntry OBJECT-TYPE: ]]
Implementers need to be aware that if the value of the
| pwPeerMappingPeerAddr (an OID) has more than 113
sub-identifiers, then OIDs of column instances in this
table will have more than 128 sub-identifiers and cannot
be accessed using SNMPv1, SNMPv2c, or SNMPv3."
It should say:
Implementers need to be aware that if the value of the
| pwPeerMappingPeerAddr corresponds to more than 113
sub-identifiers, then OIDs of column instances in this
table will have more than 128 sub-identifiers and cannot
be accessed using SNMPv1, SNMPv2c, or SNMPv3."
Notes:
Rationale:
pwPeerMappingPeerAddr is an OCTET STRING, not an OID;
cf. EID=1864.
--VERIFIER NOTES--
The original text is correct and easily understood by a MIB experts.
Errata ID: 1871
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2012-02-21
Section 12, pg.45 says:
[[ 2nd para of DESCRIPTION clause for pwGenFecIndexMappingEntry OBJECT-TYPE: ]]
Implementers need to be aware that if the combined value
of pwGenFecIndexMappingAGI, pwGenFecIndexMappingLocalAII,
| and pwGenFecIndexMappingRemoteAII (OIDs) has more than
| 113 sub-identifiers, then OIDs of column instances
in this table will have more than 128 sub-identifiers
and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."
It should say:
Implementers need to be aware that if the combined value
of pwGenFecIndexMappingAGI, pwGenFecIndexMappingLocalAII,
| and pwGenFecIndexMappingRemoteAII corresponds to more
| than 113 sub-identifiers, then OIDs of column instances
in this table will have more than 128 sub-identifiers
and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."
Notes:
Rationale (cf. EID=1864 and EID=1866):
These objects conceptually are not OIDs; they become mapped to
relative OIDs when used as INDEX variables. The corrected text
attempts this clarification with minimal textual footprint.
--VERIFIER NOTES--
The original text is correct and easily understood by a MIB experts.
Errata ID: 1872
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2011-08-03
Section 12, pg.46 says:
a) [[ DESCRIPTION clause for pwGenFecIndexMappingLocalAII OBJECT-TYPE ]]
"This object is an octet string representing the local
forwarder attachment individual identifier (AII) to be used
by this PW. It is used as the SAII for outgoing signaling
| messages and the TAII in the incoming messages from the
peer."
b) [[ DESCRIPTION clause for pwGenFecIndexMappingRemoteAII OBJECT-TYPE ]]
"This object is an octet string representing the peer
forwarder attachment individual identifier (AII) to be used
by this PW. It is used as the TAII for outgoing signaling
| messages and the SAII in the incoming messages from the
peer."
It should say:
a)
"This object is an octet string representing the local
forwarder attachment individual identifier (AII) to be used
by this PW. It is used as the SAII for outgoing signaling
| messages and expected as the TAII in the incoming messages
from the peer."
b)
"This object is an octet string representing the peer
forwarder attachment individual identifier (AII) to be used
by this PW. It is used as the TAII for outgoing signaling
| messages and expected as the SAII in the incoming messages
from the peer."
Notes:
Rationale: same as for EID=1858 !
--VERIFIER NOTES--
The original text looks clear
Errata ID: 1858
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2011-08-03
Section 12, pg.19/20 says:
a) [[ DESCRIPTION clause for pwLocalAttachmentID OBJECT-TYPE,
at the bottom of page 19: ]]
"This object is an octet string representing the local
forwarder attachment individual identifier (AII) to be
used by this PW. It is used as the Source AII (SAII) for
| outgoing signaling messages and the Target AII (TAII) in
the incoming messages from the peer. Applicable if
pwOwner equal 'genFecSignaling'."
b) [[ DESCRIPTION clause for pwRemoteAttachmentID OBJECT-TYPE,
on top of page 20: ]]
"This object is an octet string representing the remote
forwarder attachment individual identifier (AII) to be
used by this PW. It is used as the TAII for outgoing
| signaling messages and the SAII in the incoming messages
from the peer.
Applicable if pwOwner equals 'genFecSignaling'."
It should say:
a)
"This object is an octet string representing the local
forwarder attachment individual identifier (AII) to be
used by this PW. It is used as the Source AII (SAII) for
| outgoing signaling messages and expected as the Target
AII (TAII) in the incoming messages from the peer.
Applicable if pwOwner equal 'genFecSignaling'."
b)
"This object is an octet string representing the remote
forwarder attachment individual identifier (AII) to be
used by this PW. It is used as the TAII for outgoing
| signaling messages and expected as the SAII in the
incoming messages from the peer.
Applicable if pwOwner equals 'genFecSignaling'."
Notes:
Rationale:
The phrase talking about "use" of a value in an incoming message
is potentially misleading. The insertion of "expected as" should
cure the issue, with minimal footprint.
--VERIFIER NOTES--
The original text clearly states the use of the object.