[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: vacmAccessTable!!
Yes you are right. Sorry, i missed reading "DEFVAL
clause for vacmAccessContextMatch" in the RFC 2575.
Anyways thx for bringing this to my attention.
chintan
--- "Wijnen, Bert (Bert)" <bwijnen@lucent.com> wrote:
> > hi,
> >
> > RFC 2575 for vacmAccessStatus does not mention any
> > condition that so and so column need to be set
> before
> > setting it to active(1). I assume since
> > vacmContextMatch does not have any DEFVAL clause
> i.e.
> > no default value, vacmContextMatch should be the
> > column which needs to be set before
> vacmAccessStatus
> > can be set to active(1).
> >
> Sorry, but as far as I can tell, RFC2575 says:
>
> vacmAccessContextMatch OBJECT-TYPE
> SYNTAX INTEGER
> { exact (1), -- exact match of
> prefix and contextName
> prefix (2) -- Only match to the
> prefix
> }
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION "If the value of this object is
> exact(1), then all
> rows where the contextName exactly
> matches
> vacmAccessContextPrefix are
> selected.
>
> If the value of this object is
> prefix(2), then all
> rows where the contextName whose
> starting octets
> exactly match
> vacmAccessContextPrefix are selected.
> This allows for a simple form of
> wildcarding.
> "
> DEFVAL { exact }
> ::= { vacmAccessEntry 4 }
>
> So clearly there is a default value of 'exact'
> Or am I misunderstanding your question?
> You are talking about
> > vacmContextMatch does not have any DEFVAL clause
> i.e.
>
> but that object does not exist, so I assumed you
> meant
> vacmAccessContextMatch
>
> Bert
>
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com