RE: available connections thoughts
"Romascanu, Dan (Dan)" <[email protected]>
| Newsgroups | gmane.ietf.hubmib,gmane.ietf.adslmib |
|---|---|
| Message-ID | <AAB4B3D3CF0F454F98272CBE187FDE2F056B2893@is0004avexu1.global.avaya.com> |
As this work is a hubmib WG item, I would remind everybody who wants to contribute to this discussion to subscribe to [email protected], in order to enjoy all the replies and discussions. Regards, Dan > -----Original Message----- > From: Bob Ray [mailto:[email protected]] > Sent: 15 March, 2004 5:14 PM > To: Menachem Dodge > Cc: [email protected]; adslmib mail list; Romascanu, Dan > (Dan); [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]> > > >