[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