RE: RE: available connections thoughts

I wonder if this discussion does not belong on ifmib mailing list?

Thanks,
Bert 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email protected]]
> Sent: maandag 15 maart 2004 23:36
> To: [email protected]
> Cc: Menachem Dodge; [email protected]; [email protected]; Mike Sneed
> Subject: [Hubmib] 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]>
> > 
> > 
> > 
> 
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
>