home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / snmp / 815 < prev    next >
Encoding:
Text File  |  1993-01-04  |  2.0 KB  |  47 lines
  1. Newsgroups: comp.protocols.snmp
  2. Path: sparky!uunet!ods!chris
  3. From: chris@ods.com (Chris Atkins)
  4. Subject: readOnly errors?
  5. Message-ID: <1993Jan4.173115.689@ods.com>
  6. Organization: Optical Data Systems, Inc.
  7. X-Newsreader: TIN [version 1.1 PL8]
  8. Date: Mon, 4 Jan 1993 17:31:15 GMT
  9. Lines: 36
  10.  
  11.  
  12. I have been working with several agents from multiple vendors and have seen a
  13. common occurance of receiving noSuchName errors for set-requests when using
  14. the read only community string.  Frequently, I try to perform sets on variables
  15. with a community string which does not have the variable as read-write in the
  16. associated community profile.  My first response is to validate the variable 
  17. name and indices and retry the request.  Finally, I check the community string
  18. and discover the true problem.
  19.  
  20. It seems that in the above situation that a more informative and correct 
  21. approach would be to return a readOnly error.  Since a successful get-request
  22. could be performed on the variable in the original community profile, the agent
  23. is not identifying any new mib variable names and this would not appear to be
  24. a security problem.
  25.  
  26. I then began looking for instruction on when the protocol specifies that a
  27. readOnly error should be returned.  The Simple Book indicates that readOnly 
  28. should be returned when "the requested operation tried to modify a variable 
  29. that, according to the community profile, may not be written:".  This seems to
  30. make sense.
  31.  
  32. I then began looking for an RFC supporting the above use of the readOnly error
  33. status.  RFC 1157 indicates that readOnly is a valid error status, but in 
  34. section 4.1.5 (The SetRequest-PDU) does not provide a rule for the receiving
  35. entity to return a readOnly error.  In fact no mention is made as to when 
  36. a readOnly error is to be returned.  This is the only error status which does
  37. not have any mention of when it is to be returned.
  38.  
  39. My questions are:
  40. 1) Have I overlooked an RFC which specifies when to return readOnly errors?
  41. 2) if not, why is readOnly a valid value for ErrorStatus?
  42.  
  43. Chris Atkins
  44. chris@ods.com
  45.  
  46.  
  47.