RE: available connections thoughts

I meant a new textual convention or enumeration, not 
RowStatus. Similar, I suppose in some ways, but capable 
of handling adminstrative blocking.

    availabilityStatus.x.y = blocked
or  availabilityStatus.x.y = available
or  availabilityStatus.x.y = inUse
or  availabilityStatus.x.y = nonexistant 

Note that "nonexistant" implies that the hypothetical 
"can connect" table would track that two interfaces cannot
physically be connected, which seems kinda pointless.  

In fact, in the prior discussion, there was no real
need for RowStatus other than to have something in the
table.  Either the tuple was there or it wasn't, correct?
That is, it was either "active" or not there.

So, I'm suggesting something on the order of...

canConnectEntry  OBJECT-TYPE
   blah blah
   INDEX { ifIndex, ifIndex }

CanConnectEntry ::=
   SEQUENCE
   {
   availabilityStatus               Integer32
   }

availabilityStatus OBJECT-TYPE
   SYNTAX Integer32
          {
             available(1),  -- can be connected
             inUse(2),      -- exclusively connected
             blocked(3)     -- administratively blocked
          }

Does that make sense?  Please excuse any syntactical errors,
I'm just trying to communicate an idea :)

Regards,
Bob Ray

On Mon, 2004-03-15 at 16:01, Romascanu, Dan (Dan) wrote:
> Actually this use of RowStatus in the EFM Cu MIB is not a good design, and may not fly with the MIB Doctors. 
> 
> Regards,
> 
> Dan
> 
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: 15 March, 2004 7:15 PM
> > To: [email protected]; [email protected]
> > Cc: [email protected]; Romascanu, Dan (Dan); 
> > [email protected]; [email protected]
> > Subject: RE: available connections thoughts
> > 
> > 
> > Bob,
> > 
> > 	"Administrative" blocking would certainly be a useful feature to
> > have in addition to the
> > physical possibility of connection. An additional field would 
> > be required in
> > the MIB as the RowStatus is read-only
> > and shows device capability.
> > 
> > 	Regards,
> > 	Menachem
> > 
> > -----Original Message-----
> > From: Bob Ray [mailto:[email protected]] 
> > Sent: Monday, March 15, 2004 5:14 PM
> > To: Menachem Dodge
> > Cc: [email protected]; adslmib mail list; [email protected];
> > [email protected]; Mike Sneed
> > Subject: available connections thoughts
> > 
> > 
> > I think the can-connect tables (Edward's 
> > efcCuAvailableStackTable and a
> > proposed InvAvailableTable) need something more than a 
> > RowStatus object.
> > That is, it would be useful to identify a possible connection as being
> > **administratively** blocked.  That is, that a connection is 
> > physically
> > possible but blocked for administrative purposes.
> > 
> > Expanding upon the broadcast video example I used in an 
> > earlier email, 
> > 
> >     If video input X can be connected to video output Y
> >     then an entry would exist in the **can connect** table.
> > 
> >     However, there may be reasons to NOT allow X to connect
> >     to Y.  The most obvious example (for me) is where a 
> >     broadcast facility might not want adult video sources 
> >     to EVER be connected to a religious video feed.
> > 
> > Less obvious examples can be constructed (i.e. data 
> > security). Does this
> > make sense?
> > 
> > Building upon this, one might have interface group constructs 
> > and group
> > level blocking - group A can connect to group B, but group A 
> > cannot connect
> > to anything from group C.
> > 
> > Thoughts?
> > 
> > -- 
> > Bob Ray <[email protected]>
> > 
> > 
-- 
Bob Ray <[email protected]>