Ira,
I don't believe that VideoSources is an adequate description for the
group, it implies a too limited set. While I do agree that PDM should
not be enumerating physical network interfaces as that is already well
covered, I do believe that PDM should enumerate all of the
MediaInterfaces (a/v sources, a/v destinations, and local mass storage
source (internal, USB, Firewire, etc.)).
Rick,
Yes, I do live and I will try to be on the call tonight.
Regards,
Raymond Rogers
Symon Communications, Inc.
(972)543-9586
-----Original Message-----
From: owner-pdm at pwg.org [mailto:owner-pdm at pwg.org] On Behalf Of Ira
McDonald
Sent: Sunday, October 28, 2007 2:00 PM
To: Richard_Landau at dell.com
Cc: pdm at pwg.org
Subject: Re: PDM> Interfaces - needs work
Hi Rick,
I don't quite agree with your conclusions.
PDM should NOT enumerate ANY network interface - the special other value
'network' should mean use the separate property VideoSourceNetworkType
with the datatype IANAifType (from the IANA Interface Types MIB). You
don't
want to go into the business of enumerating network physical and
datalink
interface types. And the types like 'USBMemory' seem underspecified -
what
FILE on that USB stick is being displayed is more interesting. And IETF
and
IANA do enumerated memory types and other storage types in the Host
Resources MIB.
I remain of the opinion "needs work".
I also think the group name should be something like VideoSource.
My two cents,
- Ira
On 10/26/07, Richard_Landau at dell.com <Richard_Landau at dell.com> wrote:
> Ira, you are not the first person we've managed to confuse with a
poorly
> chosen name and an insufficiently explicit description. We should
> probably rename it to the "Connector" group.
>> The MIB2 Interfaces group is for network interfaces. The PDM group is
> for video and audio data-delivery interfaces. (Only two of them
> accidentally are also network interfaces, but there's not much
> network-ish about them in this application.) The group has two
> purposes:
> - Through which physical connector is the device currently (attempting
> to) receive its video signal? Same for audio signal?
> - From which physical connectors should the device look for video and
> audio signals?
>> The only properties that these objects might share with the Interface
> group are Description, maybe Type, and maybe AdminStatus. All the
other
> properties of Interface are for bit-byte-packet oriented interfaces,
> which almost all of these *analog* gezintas are not.
>> To the extent that network interfaces (ethernet and wireless) might
> appear here at all, the only "extension" would be something like
"don't
> listen to this interface for video signals." This is not very similar
> to prtChannel, either: we are not planning to enable/disable
individual
> data paths. It's strictly physical. But neither does it turn off the
> whole connector, e.g., ethernet would still carry management traffic.
> This is an instruction to the video processor to listen to the gezinta
> or not.
>> Since the network attributes are irrelevant to these connectors, and
> these functions are irrelevant to the network interfaces, I don't
> believe they ought to be combined.
>> Shared properties? The intersection of the two sets of Types is
almost
> empty. The AdminStatus has odd enum values that do not mesh with the
> way people think about these connectors, but could be used. And
> OperStatus is not reported by these devices. Not much fertile ground
> here, but maybe non-zero.
>> If IANA has a registry of these connectors, well, I missed it. 99% of
> these connectors are not Internet anything, so it's not surprising
that
> IANA doesn't collect them. They have a video *media* registry, but
that
> doesn't help much. But VESA and CEA do define these connector types,
> though not quite up to the level of a formal registry. Nick is
> investigating the collection of those definitions.
>> Seem reasonable?
>> rick
>>> -----Original Message-----
> From: owner-pdm at pwg.org [mailto:owner-pdm at pwg.org] On Behalf Of Ira
> McDonald
> Sent: Thursday, October 25, 2007 20:29
> To: pdm at pwg.org; Ira McDonald
> Subject: PDM> Interfaces - needs work
>> Hi,
>> Comments on PDM Interfaces group:
>> All SNMP Agents must implement the required groups in MIB-II (per the
> core SNMP protocol specs for all three versions), including the
> Interfaces group (which includes all local and network data interfaces
> but NOT memory, video, etc., like the PDM group).
>> The PDM Interfaces group should *augment*, rather than attempt to
> replace the MIB-II required group for local and network data
interfaces
> (802.11, 802.3 (aka Ethernet), etc.).
>> I'll send a more detailed suggestion after I think about it a bit
more,
> but we do NOT want to compete with the exstensive IANA registry of
> local/network data interface types - waste of time and effort.
>> FWIW - Host Resources MIB (RFC 2790) treats as distinct device
> types: Network, Video, Audio, Disk Storage, Parallel, and Serial
(among
> others).
>> Cheers,
> - Ira
>>> --
> Ira McDonald (Musician / Software Architect) Chair - Linux Foundation
> Open Printing WG Blue Roof Music / High North Inc PO Box 221 Grand
> Marais, MI 49839
> work: +1-906-494-2434
> home: +1-906-494-2697
> email: blueroofmusic at gmail.com>
--
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
work: +1-906-494-2434
home: +1-906-494-2697
email: blueroofmusic at gmail.com
Notice of Confidentiality: This transmission contains information that may be confidential and that may also be privileged. Unless you are the intended recipient of the message (or authorized to receive it for the intended recipient) you may not copy, forward, or otherwise use it, or disclose its contents to anyone else. If you have received this transmission in error, please notify us immediately and delete it from your system.