Re: Last Call: Definitions of Managed Objects for the Fourth Version

["Jeffrey T. Johnson" <[e-mail]>]

IESG Secretary sez:
>
>
>The IESG has received a request from the Inter-Domain Routing Working
>Group to consider:
>
>Definitions of Managed Objects for the Fourth Version of Border Gateway
>Protocol (BGP-4) <draft-ietf-idr-bgp4-mib-00.txt>
>
>for the status of Draft Standard. This is an update to RFC1657,
>currently a Proposed Standard.

I have a procedural question and a technical comment.

Question: can this document proceed to Draft Standard even though
it depends on documents that are only at Proposed Standard,
specificially RFC 1442?  As an aside, I'm surprised to see that
RFC 1442 was omitted from the References section of the document.

Comment: the two notifications defined in the mib are defined in
such a manner that they cannot be represented in an SNMPv1 trap
pdu.  Here is why:
In SNMPv1, a trap is uniquely identified by an enterprise field
(an OBJECT IDENTIFIER), a generic trap field (an integer), and
a specific trap field (an integer).
In SNMPv2, a trap is uniquely identified by a single OBJECT IDENTIFIER.

RFC 1452 section 3.1.2  provides a mechanism for mapping a V1 Trap-PDU
into a SNMPv2-Trap-PDU.  Of interest is the following excerpt:

          (2)  If a Trap-PDU is received, then it is mapped into a
               SNMPv2-Trap-PDU.  This is done by prepending onto the
               variable-bindings field two new bindings: sysUpTime.0
               [12], which takes its value from the timestamp field of
               the Trap-PDU; and, snmpTrapOID.0 [13], which is
               calculated thusly: if the value of generic-trap field is
               `enterpriseSpecific', then the value used is the
               concatenation of the enterprise field from the Trap-PDU
               with two additional sub-identifiers, `0', and the value
               of the specific-trap field; otherwise, the value of the
               corresponding trap defined in [13] is used.

Unfortunately, since the goal of the SNMPv2 working group was to
promote a quick transition to SNMPv2, no inverse mapping was defined.
This was unfortunate.  You see, the reverse mapping is as follows:
if the value of snmpTrapOID.0 is one of the traps defined in [13]
(which is RFC 1450), then the enterprise field is set to "snmp",
the generic-trap field is set to the appropriate value, and the
specific-trap field is set to 0, otherwise:
o  the specific-trap field is set to the last sub-identifier of
   the value of snmpTrapOID.0
o  the next-to-last subidentifer, which should be a zero, is ignored
o  the enterprise field is set to the value of snmpTrapOID.0 with
   the last two sub-identifiers removed.

In order to work in a V1/V2 proxy environment, the next-to-last
sub-identifier must have a value of zero.  The notifications
defined in draft-ietf-idr-bgp4-mib-00.txt do not meet this criteria.
As a result, there is no way to map these notifications into a
v1 Trap-PDU.

The SNMPv2 working group has recognized that this is a generic problem
with the NOTIFICATION-TYPE macro, and the following text currently
appears in draft-ietf-snmpv2-smi-ds-04.txt which is currently before
the IESG as a replacement for RFC 1442:

  8.5.  Mapping of the NOTIFICATION-TYPE value

  The value of an invocation of the NOTIFICATION-TYPE macro is the name of
  the notification, which is an OBJECT IDENTIFIER, an administratively
  assigned name.  In order to achieve compatibility with the procedures
  employed by proxy agents (see Section 3.1.2 of [7]), the next to last
  sub-identifier in the name of any newly-defined notification must have
  the value zero.


In the absence of conformance with the "next to last sub-identifier"
rule, text should be added to the draft to describe the mechanism
for mapping the notifications into a V1 Trap-PDU.

Regards,
/jeff