The MPLS WG Archive

[Arun Viswanathan <arun@force10networks.com>]

Joan,

> > >Joan's comments in ():
> > >(This may or may not be the case, it is not yet
> > >defined what the interactions between the Policy Agent and
> > >the SNMP Agent are going to be.  You have no way to know
> > >if the Policy Agent will be able to inform the SNMP Agent
> > >to create a Row or any other MIB entries for that matter.
> > 
> >          As you pointed out, it may or may not be the case. We
> > are focusing on the "may" case. I believe the original request
> > for this object came from one of the reference implementations.
> 
> 
> It is not acceptable to put enums like this in a standard mib
> which "may" be defined.  If the interaction between a policyAgent
> and an SNMP Agent for row-creation is ever defined, it is a long
> long way off (YEARS).

For some it may be years away, perhaps not so for others.
Besides, the policy agent doesn't have to go through SNMP agent
to create entries in the table. There is no need for a standard
on how policy agent creates entries in the LIB.

>   By then this MIB will be on its 57th 
> revision :)

At this rate even version 1 looks remote to me :-)

> 
> There is not one other standard's track MIB which indicates whether a
> row was created by a policyAgent/PIB vs. a snmpAgent/MIB.
> If someone really wants this enum then it belongs in their enterprise
> MIB and NOT in a standard MIB.
> 
> Could you take this policyAgent enum out now and put it in
> when someone describes how a Policy Agent instructs an SNMP agent
> to create a row? 
> 
> If you could remove the policyAgent enum and the SNMP enum and
> just use a generic "mgmt" enum, that would be an acceptable
> alternative.

What your are suggesting is useless and doesn't serve any purpose.
Just defining one enum defeats the whole purpose of this object.
How do you suggest we track which entity created a row in this
table?

> 
> Also, I disagree with the premise that the row needs to be destroyed
> by the same protocol which created it.

This is a non-issue. This is an implementation choice.

>  If a human being wants to
> take down an LSP which was created via signalling what is the problem
> with that?

Same as above.

>  I would also like to understand what the agent is supposed
> to return for an error code in this situation?
> 

I think you are laboring a rather innocuous but useful object.
The ONLY purpose of the object is to track which entity created
an entry in the table for the purpose of trouble-shooting and
reporting. The object's purpose is NOT to allow or disallow an
entity from creating entries into LIB. So, even if we choose
to remove some of the enum doesn't mean those entities cannot
create rows in the LIB. 

-arun