home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / snmp / 818 < prev    next >
Encoding:
Text File  |  1993-01-05  |  4.0 KB  |  86 lines
  1. Newsgroups: comp.protocols.snmp
  2. Path: sparky!uunet!psinntp!wrldlnk!usenet
  3. From: "Bernd Finkemeyer" <p00122@psilink.com>
  4. Subject: Re: readOnly errors?
  5. Message-ID: <2935352185.0.p00122@psilink.com>
  6. Sender: usenet@worldlink.com
  7. Nntp-Posting-Host: 127.0.0.1
  8. Organization: Bear Software
  9. Date: Tue, 5 Jan 1993 21:43:26 GMT
  10. X-Mailer: PSILink-DOS (3.3)
  11. Lines: 73
  12.  
  13. | The following article was relayed from Mr. William Stallings on Compuserve.
  14. | Please send private responses to him at "72500.3562@compuserve.com".
  15.  
  16. >My questions are:
  17. >1) Have I overlooked an RFC which specifies when
  18. >to return readOnly errors?
  19. >2) if not, why is readOnly a valid value for ErrorStatus?
  20.  
  21. The definition of the SetRequest PDU in RFC 1157 includes the
  22. following rule:
  23.  
  24. If, for any object named in the variable-bindings field, the
  25. object is not available for set operations in the relevant MIB
  26. view, then the receiving entity sends to the originator of the
  27. received message the GetResponse-PDU of identical form,
  28. except that the value of the error-status field is noSuchName,
  29. and the value of the error-index field is the index of said object
  30. name component in the received message.
  31.  
  32.         This rule is interpreted to mean the following:
  33.  
  34.         1.      If a set operation is attempted for an object that is 
  35. not in
  36. the MIB view of the manager, return noSuchName.
  37.         2.      If a set operation is attempted for an object that is in the
  38. MIB view of the manager but is read-only, return
  39. noSuchName.
  40.  
  41.         One can use the line of reasoning that an object that is read-
  42. only is not in the MIB view of a manager for purposes of set
  43. operations. There are two things "wrong" with this rule. First,
  44. information is lost; when a manager receives noSuchName in
  45. response to a set, the manager must also do a get operation to
  46. determine if the error code refers to a missing object or a read-only
  47. object. Second, since the readOnly error code exists, it is clearly
  48. confusing not to use it in the obvious circumstances.
  49.         The solution to this mystery is that the use of readOnly was
  50. omitted in RFC 1157 due to a clerical error. The only occurrence of
  51. readOnly in RFC 1157 is in the ASN.1 PDU definitions. Therefore, to
  52. be compliant with the standard, one must not use this error code.
  53.         The further history of readOnly is worth mentioning. Secure
  54. SNMP, which is a security enhancement to SNMP makes use of an
  55. access-control table in addition to the ACCESS clause in the OBJECT-
  56. TYPE macro. The access-control table enables an agent to specify
  57. which protocol operations are allowed to a given manager in a given
  58. context. If the access-control table dictates that only get and get-next
  59. operations are allowed, and an agent receives a set PDU, then the
  60. resulting GetResponse includes an error-status of readOnly. This is
  61. true even if the ACCESS clause for the requested object has the value
  62. read-write; the access-control entry for the entire MIB view takes
  63. precedence over the ACCESS property of the individual object. This
  64. policy makes some sense, since for the purposes of this access, all of
  65. the objects in the MIB view are only available via read-type
  66. operations (get, get-next). Nevertheless, it is somewhat misleading,
  67. especially since the readOnly code is not used in the original SNMP.
  68. Moreover, it gets worse. If for some strange reason, the access-
  69. control table dictates that only set operations are allowed (a sort of
  70. "write-only" access policy), and an attempt is made to perform a get
  71. or a get-next, then the resulting GetResponse includes an error-status
  72. of readOnly! The rationale for all of this is that the desired
  73. functionality of secure SNMP could be achieved without changing the
  74. ASN.1 definition of the SNMP PDUs.
  75.         Finally, there is the Simple Network Management Protocol
  76. version 2 (SNMPv2). In this specification, there are two new error
  77. codes: notWritable, which means what readOnly should have meant
  78. in RFC 1157 but didn't, and authorizationError, which means what
  79. RFC 1351 said readOnly meant.
  80.         Got that?
  81.  
  82. Bill Stallings
  83.  
  84. (72500.3562@compuserve.com)
  85.  
  86.