栏目搜索
 
 
 
 
你的位置:首页 > 协议大全 > RFC4088 - Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP) >
 

RFC4088 - Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)

发布者:[本站编辑] | 来源:[]

RFC4088 - Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)_电脑维修资料库

network working group d. blackrequest for comments: 4088 emc corporationcategory: standards track k. mccloghriecisco systemsj. schoenwaelderinternational university bremenjune 2005uniform resource identifier (uri) scheme for thesimple network management protocol (snmp)status of this memothis document specifies an internet standards track protocol for theinternet community, and requests discussion and suggestions forimprovements. please refer to the current edition of the internetofficial protocol standards (std 1) for the standardization stateand status of this protocol. distribution of this memo is unlimited.copyright noticecopyright (c) the internet society (2005).abstractthe simple network management protocol (snmp) and the internetstandard management framework are widely used for the management ofcommunication devices, creating a need to specify snmp access(including access to snmp mib object instances) from non-snmpmanagement environments. for example, when out-of-band ip managementis used via a separate management interface (e.g., for a device thatdoes not support in-band ip access), a uniform way to indicate how tocontact the device for management is needed. uniform resourceidentifiers (uris) fit this need well, as they allow a single textstring to indicate a management access communication endpoint for awide variety of ip-based protocols.this document defines a uri scheme so that snmp can be designated asthe protocol used for management. the scheme also allows a uri todesignate one or more mib object instances.table of contents1. introduction.................................................. 22. usage......................................................... 33. syntax of an snmp uri......................................... 43.1. relative reference considerations........................ 54. semantics and operations...................................... 64.1. snmp service uris........................................ 64.2. snmp object uris......................................... 74.2.1. snmp object uri data access....................... 84.3. oid groups in snmp uris.................................. 104.4. interoperability considerations.......................... 105. examples...................................................... 116. security considerations....................................... 126.1. snmp uri to snmp gateway security considerations......... 137. iana considerations........................................... 148. normative references.......................................... 149. informative references........................................ 1510. acknowledgements............................................. 16appendix a. registration template................................ 171. introductionsnmp and the internet-standard management framework were originallydevised to manage ip devices via in-band means, in which managementaccess is primarily via the same interface(s) used to send andreceive ip traffic. snmp's wide adoption has resulted in its use formanaging communication devices that do not support in-band ip access(e.g., fibre channel devices); a separate out-of-band ip interface isoften used for management. uris provide a convenient way to locatethat interface and specify the protocol to be used for management;one possible scenario is for an in-band query to return a uri thatindicates how the device is managed. this document specifies a urischeme to permit snmp (including a specific snmp context) to bedesignated as the management protocol by such a uri. this schemealso allows a uri to refer to specific object instances within ansnmp mib.for a detailed overview of the documents that describe the currentinternet-standard management framework, please refer to section 7 of.the key words must, must not, required, shall, shall not,should, should not, recommended, may, and optional in thisdocument are to be interpreted as described in .2. usagethere are two major classes of snmp uri usage: configuration andgateways between snmp and other protocols that use snmp uris.an snmp uri used for configuration indicates the location ofmanagement information as part of the configuration of an applicationcontaining an snmp manager. the uri can be obtained from aconfiguration file or may be provided by a managed device (seesection 1 for an example). management information is exchangedbetween the snmp manager and agent, but it does not flow beyond themanager, as shown in the following diagram:*********** snmp-request ********** *================>* *uri ---------->* manager * * agent ** *<================* ************ snmp-response *********^|other config info ------------+additional configuration information (e.g., a security secret or key)may be provided via an interface other than that used for the uri.for example, when a managed device provides an snmp uri in anunprotected fashion, that device should not provide a secret or keyrequired to use the uri. the secret or key should instead be pre-configured in or pre-authorized to the manager; see section 6.for gateway usage, clients employ snmp uris to request managementinformation via an snmp uri to snmp gateway (also called an snmpgateway in this document). the snmp manager within the snmp gatewayaccesses the management information and returns it to the requestingclient, as shown in the following diagram:snmp gateway********** uri *********** snmp-request ********** *===========>* *================>* ** client * * manager * * agent ** *<===========* *<================* *********** info *********** snmp-response *********^|other config info ------------+additional configuration information (e.g., security secrets or keys)may be provided via an interface other than that used for the uri.for example, some types of security information, including secretsand keys, should be pre-configured in or pre-authorized to themanager rather than be provided by the client; see section 6.3. syntax of an snmp urian snmp uri has the following abnf syntax, based on theabnf syntax rules for userinfo, host, port, and (path) segment in and the abnf syntax rule for hexdig in :snmp-uri = snmp:// snmp-authority < context < oids >>snmp-authority = < securityname @ > host < : port >securityname = userinfo ; snmp securitynamecontext = / contextname < ; contextengineid >contextname = segment ; snmp contextnamecontextengineid = 1*(hexdig hexdig) ; snmp contextengineidoids = / ( oid / oid-group ) < suffix >oid-group = ( oid *( , oid ) )oid = < as specified by >suffix = + / .*the userinfo and (path) segment abnf rules are reused for syntaxonly. in contrast, host and port have both the syntax and semanticsspecified in . see for the semantics ofsecurityname, contextengineid, and contextname.the snmp-authority syntax matches the uri authority syntax in section3.2 of , with the additional restriction that the userinfocomponent of an authority (when present) must be an snmpsecurityname. if the securityname is empty or not given, the entitymaking use of an snmp uri is expected to know what snmp securitynameto use if one is required. inclusion of authentication information(e.g., passwords) in uris has been deprecated (see section 3.2.1 of), so any secret or key required for snmp access must beprovided via other means that may be out-of-band with respect tocommunication of the uri. if the port is empty or not given, port161 is assumed.if the contextname is empty or not given, the zero-length string ()is assumed, as it is the default snmp context. an snmpcontextengineid is a variable-format binary element that is usuallydiscovered by an snmp manager. an snmp uri encodes a contextengineidas hexadecimal digits corresponding to a sequence of bytes. if thecontextengineid is empty or not given, the context engine is to bediscovered by querying the snmp agent at the specified host and port;see section 4.1 below. the contextengineid component of the urishould be present if more than one context engine at the designatedhost and port supports the designated context.an snmp uri that designates the default snmp context () may endwith the / character that introduces the contextname component. ansnmp uri must not end with the / character that introduces an oidor oid-group component, as the empty string is not a valid oid forsnmp.the encoding rules specified in must be used for snmp uris,including the use of percent encoding (% followed by two hexdigits) as needed to represent characters defined as reserved in and any characters not allowed in a uri. snmp permits anyutf-8 character to be used in a securityname or contextname; allmulti-byte utf-8 characters in an snmp uri must be percent encoded asspecified in sections 2.1 and 2.5 of . these requirementsare a consequence of reusing the abnf syntax rules for userinfo andsegment from .snmp uris will generally be short enough to avoid implementationstring-length limits (e.g., that may occur at 255 characters). suchlimits may be a concern for large oid groups; relative references touris (see section 4.2 of ) may provide an alternative insome circumstances.use of ip addresses in snmp uris is acceptable in situations wheredependence on availability of dns service is undesirable or must beavoided; otherwise, ip addresses should not be used (see for further explanation).3.1. relative reference considerationsuse of the snmp default context (zero-length string) within an snmpuri can result in a second instance of // in the uri, such as thefollowing:snmp:////this is allowed by syntax; if a uri parser does not handlethe second // correctly, the parser is broken and needs to befixed. this example is important because use of the snmp defaultcontext in snmp uris is expected to be common.on the other hand, the second occurrence of // in an absolute snmpuri affects usage of relative references to that uri (see section 4.2of ) because a // at the start of a relative referencealways introduces a uri authority component (host plus optionaluserinfo and/or port; see ). specifically, a relativereference of the form // will not work, because the // willcause to be parsed as a uri authority, resulting in a syntaxerror when the parser fails to find a host in . to avoid thisproblem, relative references that start with // but do not containa uri authority component must not be used. functionality equivalentto any such forbidden relative reference can be obtained by prefixing. or .. to the forbidden relative reference (e.g., ..//).the prefix to use depends on the base uri.4. semantics and operationsan snmp uri that does not include any oids is called an snmp serviceuri because it designates a communication endpoint for access to snmpmanagement service. an snmp uri that includes one or more oids iscalled an snmp object uri because it designates one or more objectinstances in an snmp mib. the expected means of using an snmp uri isto employ an snmp manager to access the snmp context designated bythe uri via the snmp agent at the host and port designated by theuri.4.1. snmp service urisan snmp service uri does not designate a data object, but rather ansnmp context to be accessed by a service; the telnet uri scheme is another example of uris that designate service access.if the contextname in the uri is empty or not given, (the zero-length string) is assumed, as it is the default snmp context.if a contextengineid is given in an snmp service uri, the contextengine that it designates is to be used. if the contextengineid isempty or not given in the uri, the context engine is to bediscovered; the context engine to be used is the one that supportsthe context designated by the uri. the contextengineid component ofthe uri should be present if more than one context engine at thedesignated host and port supports the designated context.many common uses of snmp uris are expected to omit (i.e., default)the contextengineid because they do not involve snmp proxy agents,which are the most common reason for multiple snmp context engines toexist at a single host and port. specifically, when an snmp agent islocal to the network interface that it manages, the agent willusually have only one context engine, in which case it is safe toomit the contextengineid component of an snmp uri. in addition, manysnmp agents that are local to a network interface support only thedefault snmp context (zero-length string).4.2. snmp object urisan snmp object uri contains one or more oids. the uri is used byfirst separating the oid or oid group (including its preceding slashplus any parentheses and suffix) and then processing the resultingsnmp service uri as specified in section 4.1 (above) to determine thesnmp context to be accessed. the oid or oid group is then used togenerate snmp operations directed to that snmp context.the semantics of an snmp object uri depend on whether the oid or oidgroup has a suffix and what that suffix is. there are three possibleformats; in each case, the mib object instances are designated withinthe snmp context specified by the service uri portion of the snmpobject uri. the semantics of an snmp object uri that contains asingle oid are as follows:(1) an oid without a suffix designates the mib object instancenamed by the oid.(2) an oid with a + suffix designates the lexically next mibobject instance following the oid.(3) an oid with a .* suffix designates the set of mib objectinstances for which the oid is a strict lexical prefix; thisdoes not include the mib object instance named by the oid.an oid group in an snmp uri consists of a set of oids in parentheses.in each case, the oid group semantics are the extension of the singleoid semantics to each oid in the group (e.g., a uri with a + suffixdesignates the set of mib object instances consisting of thelexically next instance for each oid in the oid group).when there is a choice among uri formats to designate the same mibobject instance or instances, the above list is in order ofpreference (no suffix is most preferable), as it runs from mostprecise to least precise. this is because an oid without a suffixprecisely designates an object instance, whereas a + suffixdesignates the next object instance, which may change, and the .*suffix could designate multiple object instances. multiplesyntactically distinct snmp uris should not be used to designate thesame mib object instance or set of instances, as this may causeunexpected results in uri-based systems that use string comparison totest uris for equality.snmp object uris designate the data to be accessed, as opposed to thespecific snmp operations to be used for access; section 4.2.1provides examples of how snmp operations can be used to access datafor snmp object uris. nonetheless, any applicable snmp operation,including getbulk, may be used to access data for all or part of oneor more snmp object uris (e.g., via use of multiple variable bindingsin a single operation); it is not necessary to use the specificoperations described in section 4.2.1 as long as the results(returned variable bindings or error) could have been obtained byfollowing section 4.2.1's descriptions. the use of relativereferences that do not change the contextname (i.e., ./) shouldbe viewed as a hint that optimization of snmp access across multiplesnmp uris may be possible.an snmp object uri may also be used to specify a mib object instanceor instances to be written; this causes generation of an snmp setoperation instead of a get. the + and .* suffixes must not beused in this case; any attempt to do so is an error that must notgenerate any snmp set operations. values to be written to the mibobject instance or instances are not specified within an snmp objecturi.snmp object uris designate data in snmp mibs and hence do not providethe means to generate all possible snmp protocol operations. forexample, data access for an snmp object uri cannot directly generateeither snmpv2-trap or informrequest notifications, although sideeffects of data access could cause such notifications (depending onthe mib). in addition, whether and how getbulk is used for an snmpobject uri with a .* suffix is implementation specific.4.2.1. snmp object uri data accessdata access based on an snmp object uri returns an snmp variablebinding for each mib object instance designated by the uri, or ansnmp error if the operation fails. an snmp variable binding binds avariable name (oid) to a value or an snmp exception (see ).the snmp operation or operations needed to access data designated byan snmp object uri depend on the oid or oid group suffix or absencethereof. the following descriptions are not the only method ofperforming data access for an snmp object uri; any suitable snmpoperations may be used as long as the results (returned variablebindings or error) are functionally equivalent.(1) for an oid or oid group without a suffix, an snmp getoperation is generated using each oid as a variable bindingname. if an snmp error occurs, that error is the result ofuri data access; otherwise, the returned variable binding orbindings are the result of uri data access. note that anyreturned variable binding may contain an snmp nosuchobjector nosuchinstance exception.(2) for an oid or oid group with a + suffix, an snmp getnextoperation is generated using each oid as a variable bindingname. if an snmp error occurs, that error is the result ofuri data access; otherwise, the returned variable binding orbindings are the result of uri data access. note that anyreturned variable binding may contain an snmp endofmibviewexception.(3) for an oid or oid group with a .* suffix, an snmp getnextoperation is initially generated using each oid as a variablebinding name. if the result is an snmp error, that error isthe result of uri data access. if all returned variablebindings contain either a) an oid for which the correspondinguri oid is not a lexical prefix or b) an snmp endofmibviewexception, then the returned variable bindings are the resultof uri data access.otherwise, the results of the getnext operation are saved, andanother snmp getnext operation is generated using the newlyreturned oids as variable binding names. this is repeated(save the results and generate a getnext with newly returnedoids as variable binding names) until all the returnedvariable bindings from a getnext contain either a) an oid forwhich the corresponding uri oid is not a lexical prefix or b)an snmp endofmibview exception. the results from all of thegetnext operations are combined to become the overall resultof uri data access; this may include variable bindings whoseoid is not a lexical extension of the corresponding uri oid.if the oid subtrees (set of oids for which a specific uri oidis a lexical prefix) are not the same size for all oids in theoid group, the largest subtree determines when this iterationends. snmp getbulk operations may be used to optimize thisiterated access.whenever a returned variable binding contains an oid for whichthe corresponding uri oid is not a lexical prefix or an snmpendofmibview exception, iteration of that element of the oidgroup may cease, reducing the number of variable bindings usedin subsequent getnext operations. in this case, the resultsof uri data access for the snmp uri will not consist entirelyof oid-group-sized sets of variable bindings. even if thisdoes not occur, the last variable binding returned for eachmember of the oid group will generally contain an snmpendofmibview exception or an oid for which the correspondinguri oid is not a lexical prefix.4.3. oid groups in snmp urisparenthesized oid groups in snmp uris are intended to support mibobject instances for which access via a single snmp operation isrequired to ensure consistent results. therefore, the oids within anoid group in an snmp uri should be accessed by a single snmpoperation containing a variable binding corresponding to each oid inthe group. a specific example involves the inetaddress andinetaddresstype textual conventions defined in , for whichthe format of an inetaddress instance is specified by an associatedinetaddresstype instance. if two such associated instances are readvia separate snmp operations, the resulting values could beinconsistent (e.g., due to an intervening set), causing theinetaddress value to be interpreted incorrectly.this single operation requirement (should) also applies to each oidgroup resulting from iterated access for an snmp uri with a .*suffix. when members of an snmp uri oid group differ in the numberof oids for which each is a lexical prefix, this iteration mayoverrun by returning numerous variable bindings for which thecorresponding oid in the oid group is not a lexical prefix. suchoverrun can be avoided by using relative references within the samecontext (i.e., ./.* ) when it is not important to accessmultiple mib object instances in a single snmp operation.4.4. interoperability considerationsthis document defines a transport-independent snmp scheme that isintended to accommodate snmp transports other than udp. udp is thedefault transport for access to information specified by an snmp urifor backward compatibility with existing usage, but other transportsmay be used. if more than one transport can be used (e.g., snmp overtcp in addition to snmp over udp), the information or snmpservice access designated by an snmp uri should not depend on whichtransport is used (for snmp over tcp, this is implied by section 2 of).an snmp uri designates use of snmpv3 as specified by ,, and related documents, but older versions of snmp may beused in accordance with when usage of such older versionsis unavoidable. for snmpv1 and snmpv2c, the securityname,contextname, and contextengineid elements of an snmp uri are mappedto/from the community name, as described in . when thecommunity name is kept secret as a weak form of authentication, thismapping should be configured so that these three elements do notreveal information about the community name. if this is not done,then any snmp uri component that would disclose significantinformation about a secret community name should be omitted. notethat some community names contain reserved characters (e.g., @)that require percent encoding when they are used in an snmp uri.snmp versions (e.g., v3) have been omitted from the snmp uri schemeto permit use of older versions of snmp, as well as any possiblefuture successor to snmpv3.5. examplessnmp://example.comthis example designates the default snmp context at the snmp agent atport 161 of host example.com .snmp://tester5@example.com:8161this example designates the default snmp context at the snmp agent atport 8161 of host example.com and indicates that the snmpsecurityname tester5 is to be used to access that agent. apossible reason to use a non-standard port is for testing a newversion of snmp agent code.snmp://example.com/bridge1this example designates the bridge1 snmp context at example.com.because the contextengineid component of the uri is omitted, thereshould be at most one snmp context engine at example.com thatsupports the bridge1 context.snmp://example.com/bridge1;800002b804616263this example designates the bridge1 context at snmp.example.com viathe snmp context engine 800002b804616263 (string representation of ahexadecimal value). this avoids ambiguity if any other contextengine supports a bridge1 context. the above two examples arebased on the figure in section 3.3 of .snmp://example.com//1.3.6.1.2.1.1.3.0snmp://example.com//1.3.6.1.2.1.1.3+snmp://example.com//1.3.6.1.2.1.1.3.*these three examples all designate the sysuptime.0 object instance inthe snmpv2-mib or rfc1213-mib for the default snmp context () atexample.com as sysuptime.0 is:a) designated directly by oid 1.3.6.1.2.1.1.3.0,b) the lexically next mib object instance after the oid1.3.6.1.2.1.1.3, andc) the only mib object instance whose oid has 1.3.6.1.2.1.1.3 as alexical prefix.these three examples are provided for illustrative purposes only, asmultiple syntactically distinct uris should not be used to designatethe same mib object instance, in order to avoid unexpected results inuri-based systems that use string comparison to test uris forequality.snmp://example.com/bridge1/1.3.6.1.2.1.2.2.1.8.*this example designates the ifoperstatus column of the if-mib in thebridge1 snmp context at example.com.snmp://example.com//(1.3.6.1.2.1.2.2.1.7,1.3.6.1.2.1.2.2.1.8).*this example designates all (ifadminstatus, ifoperstatus) pairs inthe if-mib in the default snmp context at example.com.6. security considerationsan intended use of this uri scheme is designation of the location ofmanagement access to communication devices. such locationinformation may be considered sensitive in some environments, makingit important to control access to this information and possibly evento encrypt it when it is sent over the network. all uses of this urischeme should provide security mechanisms appropriate to theenvironments in which such uses are likely to be deployed.the snmp architecture includes control of access to managementinformation (see section 4.3 of ). an snmp uri does notcontain sufficient security information to obtain access in allsituations, as the snmp uri syntax is incapable of encoding snmpsecuritymodels, snmp securitylevels, and credential or keyinginformation for snmp securitynames. other means are necessary toprovide such information; one possibility is out-of-band pre-configuration of the snmp manager, as shown in the diagrams insection 2.by itself, the presence of a securityname in an snmp uri does notauthorize use of that securityname to access management information.instead, the snmp manager should match the securityname in the uri toan snmp securityname and associated security information that havebeen pre-configured for use by the manager. if an snmp uri containsa securityname that the snmp manager is not provisioned to use, snmpoperations for that uri should not be generated.snmp versions prior to snmpv3 did not include adequate security.even if the network itself is secure (for example, via use of ipsec),there is no control over who on the secure network is allowed toaccess and get/set (read/change/create/delete) the objects in mibmodules. it is recommended that implementers consider the securityfeatures provided by the snmpv3 framework (see , section 8,for an overview), including full support for snmpv3 cryptographicmechanisms (for authentication and privacy). this is of additionalimportance for mib elements considered sensitive or vulnerablebecause gets have side effects.further, deployment of snmp versions prior to snmpv3 is notrecommended. instead, it is recommended to deploy snmpv3 and toenable cryptographic security. it is then a customer/operatorresponsibility to ensure that the snmp entity giving access to a mibmodule instance is properly configured to give access to the objectsonly to those principals (users) that have legitimate rights toindeed get or set (read/change/create/delete) them.6.1. snmp uri to snmp gateway security considerationsadditional security considerations apply to snmp gateways thatgenerate snmp operations for snmp uris and return the results toclients (see section 2) because management information iscommunicated beyond the snmp framework. in general, an snmp gatewayshould have some knowledge of the structure and function of themanagement information that it accesses via snmp. among otherbenefits, this allows an snmp gateway to avoid snmp access controlfailures because the gateway can reject an snmp uri that will causesuch failures before generating any snmp operations.snmp gateways should impose authorization or access-control checks onall clients. if an snmp gateway does not impose authorization oraccess controls, the gateway must not automatically obtain or usesnmp authentication material for arbitrary securitynames, as doing sowould defeat snmp's access controls. instead, all snmp gatewaysshould authenticate each client and check the client's authorizationto use a securityname in an snmp uri before using the securityname onbehalf of that client.an snmp gateway is also responsible for ensuring that all of itscommunication is appropriately secured. specifically, an snmpgateway should ensure that communication of management informationwith any client is protected to at least the snmp securitylevel usedfor the corresponding snmp access (see section 3.4.3 of formore information on securitylevel). if the client provides snmpsecurity information, the snmp gateway should authenticate the clientand should ensure that an authenticated cryptographic integrity checkis used for that communication to prevent modification of thesecurity information. in addition, if a client provides any key orsecret, the snmp gateway should ensure that encryption is used inaddition to the integrity check for that communication to preventdisclosure of keys or secrets.there are management objects defined in snmp mibs whose max-access isread-write and/or read-create. such objects may be consideredsensitive or vulnerable in some network environments. snmp gatewaysupport for snmp set operations in a non-secure environment withoutproper protection can have a negative effect on network operations.the individual mib module specifications, and especially theirsecurity considerations, should be consulted for further information.some readable objects in some mib modules (i.e., objects with a max-access other than not-accessible) may be considered sensitive orvulnerable in some network environments. it is thus important tocontrol even get access to these objects via an snmp gateway andpossibly to even encrypt the values of these objects when they aresent over the network. the individual mib module specifications, andespecially their security considerations, should be consulted forfurther information. this consideration also applies to objects forwhich read operations have side effects.7. iana considerationsthe iana has registered the url registration template found inappendix a in accordance with .8. normative references bradner, s., key words for use in rfcs to indicaterequirement levels, bcp 14, rfc 2119, march 1997. crocker, d. and p. overell, augmented bnf for syntaxspecifications: abnf, rfc 2234, november 1997. mealling, m., a urn namespace of object identifiers, rfc3061, february 2001. harrington, d., presuhn, r., and b. wijnen, anarchitecture for describing simple network managementprotocol (snmp) management frameworks, std 62, rfc 3411,december 2002. presuhn, r., version 2 of the protocol operations for thesimple network management protocol (snmp), std 62, rfc3416, december 2002. presuhn, r., transport mappings for the simple networkmanagement protocol (snmp), std 62, rfc 3417, december2002. frye, r., levi, d., routhier, s., and b. wijnen,coexistence between version 1, version 2, and version 3 ofthe internet-standard network management framework, bcp74, rfc 3584, august 2003. berners-lee, t., fielding, r., and l. masinter, uniformresource identifier (uri): generic syntax, std 66, rfc3986, january 2005.9. informative references berners-lee, t., masinter, l., and m. mccahill, uniformresource locators (url), rfc 1738, december 1994. carpenter, b. and y. rekhter, renumbering needs work, rfc1900, february 1996. petke, r. and i. king, registration procedures for urlscheme names, bcp 35, rfc 2717, november 1999. case, j., mundy, r., partain, d., and b. stewart,introduction and applicability statements for internet-standard management framework, rfc 3410, december 2002. schoenwaelder, j., simple network management protocol overtransmission control protocol transport mapping, rfc 3430,december 2002. lear, e., uniform resource identifier (uri) scheme andapplicability statement for the trivial file transferprotocol (tftp), rfc 3617, october 2003. daniele, m., haberman, b., routhier, s., and j.schoenwaelder, textual conventions for internet networkaddresses, rfc 4001, february 2005.10. acknowledgementsportions of this document were adapted from eliot lear's tftp urischeme specification . portions of the securityconsiderations were adapted from the widely used securityconsiderations boilerplate for mib modules. comments from tedhardie, michael mealing, larry masinter, frank strauss, bert wijnen,steve bellovin, the mreview@ops.ietf.org mailing list and theuri@w3c.org mailing list on earlier versions of this document haveresulted in significant improvements and are gratefully acknowledged.appendix a. registration templateurl scheme name: snmpurl scheme syntax: section 3character encoding considerations: section 3intended usage: sections 1 and 2applications and/or protocols which use this scheme: snmp, allversions, see and . also snmp over tcp,see .interoperability considerations: section 4.4security considerations: section 6relevant publications: see for list. also and .contact: david l. black, see belowauthor/change controller: iesgauthors' addressesdavid l. blackemc corporation176 south streethopkinton, ma 01748phone: +1 (508) 293-7953email: black_david@emc.comkeith mccloghriecisco systems, inc.170 west tasman drivesan jose, ca usa 95134phone: +1 (408) 526-5260email: kzm@cisco.comjuergen schoenwaelderinternational university bremenp.o. box 750 56128725 bremengermanyphone: +49 421 200 3587email: j.schoenwaelder@iu-bremen.defull copyright statementcopyright (c) the internet society (2005).this document is subject to the rights, licenses and restrictionscontained in bcp 78, and except as set forth therein, the authorsretain all their rights.this document and the information contained herein are provided on anas is basis and the contributor, the organization he/she representsor is sponsored by (if any), the internet society and the internetengineering task force disclaim all warranties, express or implied,including but not limited to any warranty that the use of theinformation herein will not infringe any rights or any impliedwarranties of merchantability or fitness for a particular purpose.intellectual propertythe ietf takes no position regarding the validity or scope of anyintellectual property rights or other rights that might be claimed topertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. informationon the procedures with respect to rights in rfc documents can befound in bcp 78 and bcp 79.copies of ipr disclosures made to the ietf secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use ofsuch proprietary rights by implementers or users of thisspecification can be obtained from the ietf on-line ipr repository athttp://www.ietf.org/ipr.the ietf invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. please address the information to the ietf at ietf-ipr@ietf.org.acknowledgementfunding for the rfc editor function is currently provided by theinternet society.</t