Re: Doubts about RFC 1445

[[e-mail]]

> In message "Doubts about RFC 1445", [e-mail] writes:

>> 
>> I'm working on the implementation of a SNMPv2 agent and encountered the
>> following problem. Could anyone give me some advice?
>> 
>> RFC 1445 (Section 3.2) describes how to process a received communication. At
>> step (14) it says :
>> 	"The local database of access policy information is
>>          consulted for access privileges permitted by the local
>>          access policy to the originating SNMPv2 party with
>>          respect to the receiving SNMPv2 party and the indicated
>>          SNMPv2 context."
>> 
>> However it does not specify what to do if this information is not found in
>> the database of access policy information. What should I do? Should I assume
>> that there is no access granted (aclPrivileges = 0)? Should I stop processing
>> the message?

> From my understanding, the access priviledges is stored together with
> the SNMP context. This is implied by the definition of "AclEntry" as
> given on page 15.
>
> In the previous step (step 13), if the context is not found, then the
> received message is discarded without further processing.
> Once step 13 passes, it implies that step 14 is sure to pass.

Michael,

First of all thank you for replaying to my message. 

I have been reading the rfc's again but I can't find the implication 
you mention in your replay. Referring to the AclEntry, page 15 of
rfc 1445 says:
	" Its aclResources component is called the managed object
	  resources and identifies the SNMPv2 context referenced by
	  the partial policy."

I believe this means that it is the AclEntry the one that contains a 
reference to the context to which the access policy is supposed to 
be applied, but not the other way round. The ContextEntry (page 29 of 
rfc 1447, Party MIB) doesn't contain any reference to the access 
policy to be applied on it.

Furthermore, the semantics of the Party MIB as defined in rfc 1447,
seem to imply that the AclTable is dependent on the context table,
i.e. it is not possible to have an AclEntry that refers to a context
that doesn't appear in the contect table. The context table, however,
may contain the description of contexts for which no access policy
is defined in the AclTable.

If I got it right, the fact that the local database of context information
is checked for information about the SNMPv2 context (step 13) does
not ensure that information about the access privileges permitted
to the originating party with respect to the receiving party and the
indicated context will be found in step 14. In this case (which may
not be) my problem remains unresolved.

Regards,
Gotzon.

context in