The group includes source connectors for all signals, video and audio,
so renaming to "VideoSource" is not adequate. Dividing into two groups
seems even less reasonable.
Describing the format of data entering a connector is *precisely* what
this group has struggled to avoid. You have not heard the discussions
on this topic. They do not want to model signal type (or file type).
It is very complicated, the types are almost entirely
connector-specific, and the details are judged not to be useful as
management information. All this group wants to control is the gezinta,
the socket (or antenna) in the back panel.
Note: information about, and control over, the gezinta sourcing the
video signal is the number three request on the management hit parade,
as I understand it, after power management and lamp status/age.
I get the point about adding a property for some IANA type.
- Adding a column property that might be used by one or two out of ten
rows is a stretch, but it's probably not unprecedented.
- Is there an IANA type that covers the *two* flavors of Ethernet needed
here?
- IANAIfJackType includes rj45, but covers only 802.3 gezintas by its
definition.
- Whence something for 802.11, particularly without specifying a, b, g,
or n? (Too much detail, as noted above.) I am not up on these things.
Please enlighten me.
- Adding *two* columns that might be used by max one out of ten rows is
a loooong stretch.
Perhaps some of the names need to be changed, e.g.,
- from "ethernet" to "rj45"
- from "wirelessEthernet" to "wirelessRadio"
to avoid confusion about their intended function.
rick
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Sunday, October 28, 2007 14:00
To: Landau, Richard
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