RE: available connections thoughts

This is better. However, your proposal lights another warning beacon for me. Would not this 'nonexistent' value lead to an un-justified multiplication of the number of rows? We should be careful here. The ifStack like models have little deployment today, and the concern about the multiplication of the number of entries in devices with multiple overlayed interfaces may be related. What is the opertional benefit from having a 'nonexistant' enumerated value defined?

Thanks and Regards,

Dan



> -----Original Message-----
> From: Bob Ray [mailto:[email protected]]
> Sent: 16 March, 2004 12:23 AM
> To: Romascanu, Dan (Dan)
> Cc: Menachem Dodge; [email protected]; [email protected]; Mike Sneed
> Subject: 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]>
> 
> 
>