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]>
> 
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.