🚀 go-pugleaf

I have been working with several agents from multiple vendors and have seen a
common occurance of receiving noSuchName errors for set-requests when using
the read only community string.  Frequently, I try to perform sets on variables
with a community string which does not have the variable as read-write in the
associated community profile.  My first response is to validate the variable 
name and indices and retry the request.  Finally, I check the community string
and discover the true problem.

It seems that in the above situation that a more informative and correct 
approach would be to return a readOnly error.  Since a successful get-request
could be performed on the variable in the original community profile, the agent
is not identifying any new mib variable names and this would not appear to be
a security problem.

I then began looking for instruction on when the protocol specifies that a
readOnly error should be returned.  The Simple Book indicates that readOnly 
should be returned when "the requested operation tried to modify a variable 
that, according to the community profile, may not be written:".  This seems to
make sense.

I then began looking for an RFC supporting the above use of the readOnly error
status.  RFC 1157 indicates that readOnly is a valid error status, but in 
section 4.1.5 (The SetRequest-PDU) does not provide a rule for the receiving
entity to return a readOnly error.  In fact no mention is made as to when 
a readOnly error is to be returned.  This is the only error status which does
not have any mention of when it is to be returned.

My questions are:
1) Have I overlooked an RFC which specifies when to return readOnly errors?
2) if not, why is readOnly a valid value for ErrorStatus?

Chris Atkins
chris@ods.com