draft-ietf-snmpv3-update-transmap-02.txt   draft-ietf-snmpv3-update-transmap-03.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Category: Standards Track J. Case Category: Standards Track J. Case
SNMP Research, Inc. SNMP Research, Inc.
K. McCloghrie K. McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
M. Rose M. Rose
Dover Beach Consulting, Inc. Dover Beach Consulting, Inc.
S. Waldbusser S. Waldbusser
International Network Services International Network Services
Transport Mappings for Transport Mappings for
the Simple Network Management Protocol the Simple Network Management Protocol
<draft-ietf-snmpv3-update-transmap-02.txt> <draft-ietf-snmpv3-update-transmap-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 4, line 8 skipping to change at page 4, line 8
This document, Transport Mappings for the Simple Network This document, Transport Mappings for the Simple Network
Management Protocol, defines how the management protocol [RFC- Management Protocol, defines how the management protocol [RFC-
PROTO] may be carried over a variety of protocol suites. It is PROTO] may be carried over a variety of protocol suites. It is
the purpose of this document to define how the SNMP maps onto an the purpose of this document to define how the SNMP maps onto an
initial set of transport domains. Other mappings may be defined initial set of transport domains. Other mappings may be defined
in the future. in the future.
Although several mappings are defined, the mapping onto UDP over Although several mappings are defined, the mapping onto UDP over
IPv4 is the preferred mapping. As such, to provide for the IPv4 is the preferred mapping. As such, to provide for the
greatest level of interoperability, systems which choose to greatest level of interoperability, systems which choose to
deploy other mappings should also provide for proxy service to deploy other mappings should also provide for access via UDP
the UDP over IPv4 mapping. over IPv4 mapping.
2. Definitions 2. Definitions
SNMPv2-TM DEFINITIONS ::= BEGIN SNMPv2-TM DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY, MODULE-IDENTITY, OBJECT-IDENTITY,
snmpModules, snmpDomains, snmpProxys snmpModules, snmpDomains, snmpProxys
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION TEXTUAL-CONVENTION
FROM SNMPv2-TC; FROM SNMPv2-TC;
snmpv2tm MODULE-IDENTITY snmpv2tm MODULE-IDENTITY
LAST-UPDATED "200004032350Z" LAST-UPDATED "200006030101Z"
ORGANIZATION "IETF SNMPv3 Working Group" ORGANIZATION "IETF SNMPv3 Working Group"
CONTACT-INFO CONTACT-INFO
"WG-EMail: snmpv3@tis.com "WG-EMail: snmpv3@tis.com
Subscribe: majordomo@tis.com Subscribe: majordomo@tis.com
In message body: subscribe snmpv3 In message body: subscribe snmpv3
Chair: Russ Mundy Chair: Russ Mundy
TIS Labs at Network Associates TIS Labs at Network Associates
postal: 3060 Washington Rd postal: 3060 Washington Rd
Glenwood MD 21738 Glenwood MD 21738
skipping to change at page 4, line 47 skipping to change at page 4, line 47
Editor: Randy Presuhn Editor: Randy Presuhn
BMC Software, Inc. BMC Software, Inc.
postal: 2141 North First Street postal: 2141 North First Street
San Jose, CA 95131 San Jose, CA 95131
USA USA
EMail: randy_presuhn@bmc.com EMail: randy_presuhn@bmc.com
phone: +1 408 546-1006" phone: +1 408 546-1006"
DESCRIPTION DESCRIPTION
"The MIB module for SNMP transport mappings." "The MIB module for SNMP transport mappings."
REVISION "200004032350Z" REVISION "200006030101Z"
DESCRIPTION DESCRIPTION
"Clarifications, published as "Clarifications, published as
<draft-ietf-snmpv3-update-transmap-02.txt>" <draft-ietf-snmpv3-update-transmap-03.txt>"
REVISION "199601010000Z" REVISION "199601010000Z"
DESCRIPTION DESCRIPTION
"Clarifications, published as RFC 1906." "Clarifications, published as RFC 1906."
REVISION "199304010000Z" REVISION "199304010000Z"
DESCRIPTION DESCRIPTION
"The initial version, published as RFC 1449." "The initial version, published as RFC 1449."
::= { snmpModules ?? } -- to be assigned by IANA?? ::= { snmpModules ?? } -- to be assigned by IANA??
-- SNMP over UDP over IPv4 -- SNMP over UDP over IPv4
skipping to change at page 7, line 31 skipping to change at page 7, line 31
5-10 physical-address network-byte order 5-10 physical-address network-byte order
11-12 socket-number network-byte order 11-12 socket-number network-byte order
" "
SYNTAX OCTET STRING (SIZE (12)) SYNTAX OCTET STRING (SIZE (12))
-- for proxy to SNMPv1 (RFC 1157) -- for proxy to SNMPv1 (RFC 1157)
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Domain OBJECT-IDENTITY rfc1157Domain OBJECT-IDENTITY
STATUS current STATUS deprecated
DESCRIPTION DESCRIPTION
"The transport domain for SNMPv1 over UDP over IPv4. "The transport domain for SNMPv1 over UDP over IPv4.
The corresponding transport address is of type The corresponding transport address is of type
SnmpUDPAddress." SnmpUDPAddress."
::= { rfc1157Proxy 1 } ::= { rfc1157Proxy 1 }
-- ::= { rfc1157Proxy 2 } this OID is obsolete -- ::= { rfc1157Proxy 2 } this OID is obsolete
END END
skipping to change at page 12, line 37 skipping to change at page 12, line 37
When an SNMP entity uses this transport mapping, it must be capable When an SNMP entity uses this transport mapping, it must be capable
of accepting messages that are at least 546 octets in size. of accepting messages that are at least 546 octets in size.
Implementation of larger values is encouraged whenever possible. Implementation of larger values is encouraged whenever possible.
7. Proxy to SNMPv1 7. Proxy to SNMPv1
Historically, in order to support proxy to SNMPv1, as defined in Historically, in order to support proxy to SNMPv1, as defined in
[RFC2576], it was deemed useful to define a transport domain, [RFC2576], it was deemed useful to define a transport domain,
rfc1157Domain, which indicates the transport mapping for SNMP rfc1157Domain, which indicates the transport mapping for SNMP
messages as defined in [RFC1157]. Subsequently, this transport messages as defined in [RFC1157].
domain has proven useful in non-proxy situations.
8. Serialization using the Basic Encoding Rules 8. Serialization using the Basic Encoding Rules
When the Basic Encoding Rules [BER] are used for serialization: When the Basic Encoding Rules [BER] are used for serialization:
(1) When encoding the length field, only the definite form is used; (1) When encoding the length field, only the definite form is used;
use of the indefinite form encoding is prohibited. Note that use of the indefinite form encoding is prohibited. Note that
when using the definite-long form, it is permissible to use more when using the definite-long form, it is permissible to use more
than the minimum number of length octets necessary to encode the than the minimum number of length octets necessary to encode the
length field. length field.
skipping to change at page 13, line 12 skipping to change at page 13, line 11
(2) When encoding the value field, the primitive form shall be used (2) When encoding the value field, the primitive form shall be used
for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
IDENTIFIER (either IMPLICIT or explicit). The constructed form IDENTIFIER (either IMPLICIT or explicit). The constructed form
of encoding shall be used only for structured types, i.e., a of encoding shall be used only for structured types, i.e., a
SEQUENCE or an IMPLICIT SEQUENCE. SEQUENCE or an IMPLICIT SEQUENCE.
(3) When encoding an object whose syntax is described using the BITS (3) When encoding an object whose syntax is described using the BITS
construct, the value is encoded as an OCTET STRING, in which all construct, the value is encoded as an OCTET STRING, in which all
the named bits in (the definition of) the bitstring, commencing the named bits in (the definition of) the bitstring, commencing
with the first bit and proceeding to the last bit, are placed in with the first bit and proceeding to the last bit, are placed in
bits 8 to 1 of the first octet, followed by bits 8 to 1 of each bits 8 (high order bit) to 1 (low order bit) of the first octet,
subsequent octet in turn, followed by as many bits as are needed followed by bits 8 to 1 of each subsequent octet in turn,
of the final subsequent octet, commencing with bit 8. Remaining followed by as many bits as are needed of the final subsequent
bits, if any, of the final octet are set to zero on generation octet, commencing with bit 8. Remaining bits, if any, of the
and ignored on receipt. final octet are set to zero on generation and ignored on
receipt.
These restrictions apply to all aspects of ASN.1 encoding, including These restrictions apply to all aspects of ASN.1 encoding, including
the message wrappers, protocol data units, and the data objects they the message wrappers, protocol data units, and the data objects they
contain. contain.
8.1. Usage Example 8.1. Usage Example
As an example of applying the Basic Encoding Rules, suppose one As an example of applying the Basic Encoding Rules, suppose one
wanted to encode an instance of the GetBulkRequest-PDU [RFC-PROTO]: wanted to encode an instance of the GetBulkRequest-PDU [RFC-PROTO]:
skipping to change at page 18, line 40 skipping to change at page 18, line 42
Rose, M., and S. Waldbusser, "Textual Conventions for Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999. SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999. SMIv2", STD 58, RFC 2580, April 1999.
[RFC-TM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. [RFC-TM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for the Simple Network Waldbusser, "Transport Mappings for the Simple Network
Management Protocol", Management Protocol",
<draft-ietf-snmpv3-update-transmap-02.txt>, April 2000. <draft-ietf-snmpv3-update-transmap-03.txt>, June 2000.
[RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for the Simple Network Waldbusser, "Protocol Operations for the Simple Network
Management Protocol", Management Protocol",
<draft-ietf-snmpv3-update-proto-02.txt>, April 2000. <draft-ietf-snmpv3-update-proto-03.txt>, June 2000.
13. Editor's Address 13. Editor's Address
Randy Presuhn Randy Presuhn
BMC Software, Inc. BMC Software, Inc.
2141 North First Street 2141 North First Street
San Jose, CA 95131 San Jose, CA 95131
USA USA
Phone: +1 408 546-1006 Phone: +1 408 546-1006
skipping to change at page 19, line 51 skipping to change at page 19, line 51
- Updated references section; - Updated references section;
- Added MODULE-IDENTITY; - Added MODULE-IDENTITY;
- Re-wrote introduction section using current boilerplate; - Re-wrote introduction section using current boilerplate;
- Added recommendation for larger message size support; - Added recommendation for larger message size support;
- Added historical background on use of rfc1157Domain with - Added historical background on use of rfc1157Domain with
proxy; proxy and changed status to "deprecated".
15. Issues 15. Issues
This section is to be deleted when it is time to publish this This section is to be deleted when it is time to publish this
document as an RFC. The issue labels are the same as those used in document as an RFC. The issue labels are the same as those used in
the on-line issues list at the on-line issues list at
ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/index.html ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/index.html
1906-01 Done; title changed. 1906-01 Done; title changed.
1906-02 Done; introduction clause replaced. 1906-02 Done; introduction clause replaced.
1906-03 1906-03
1906-04 Done; resolution required no changes. 1906-04 Done; resolution required no changes.
1906-05 Done; typo in SnmpNBPAddress fixed. 1906-05 Done; typo in SnmpNBPAddress fixed.
1906-06 1906-06 See issue 1906-10.
1906-07 Done; use of manager/agent terminology replaced with 1906-07 Done; use of manager/agent terminology replaced with
terms from architecture. terms from architecture.
1906-08 Done; added recommendation for support of 1472 byte 1906-08 Done; added recommendation for support of 1472 byte
messages. messages.
1906-09 Done; resolution required no changes. 1906-09 Done; resolution required no changes.
1906-10 Done; added historical background to material on proxy. 1906-10 Done; resolved by deprecating the definition.
Note that some are unhappy with this text; a better
replacement would be most welcome.
1906-11 Done; resolution required no changes. 1906-11 Done; resolution required no changes.
1906-12 Done; resolution required no changes. 1906-12 Done; resolution required no changes.
1906-13 Done; resolution required no changes. 1906-13 Done; resolution required no changes.
1906-14 Done; clarified that BER SEQUENCE comes from ASN.1 1906-14 Done; clarified that BER SEQUENCE comes from ASN.1
SEQUENCE OF. SEQUENCE OF.
1906-15 Done; security considerations text added. 1906-15 Done; security considerations text added.
1906-16 Done; references and acknowledgments updated. 1906-16 Done; references and acknowledgments updated.
1906-17 Done; IPR and copyright notices updated. 1906-17 Done; IPR and copyright notices updated.
1906-18 Done; resolution required no changes. 1906-18 Done; resolution required no changes.
1906-19 Done; MODULE-IDENTITY added. 1906-19 Done; MODULE-IDENTITY added.
1906-20 Done; resolution was to make no change.
16. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
 End of changes. 14 change blocks. 
21 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/