Hi,
All interesting details, but...
For the same reason you have fine-grained groups like ThermalSensor,
you should probably have (at a minimum), a VideoInput and VideoOutput
and AudioInput and AudioOutput group. Wherever possible, these should
leverage IETF/IANA, VESA, IEEE, or whatever registries of standard types.
:"Wireless Radio" is actively bad, because it makes no distinction between
Bluetooth, 802.11, satellite, and various new MAN and WAN wireless.
Bluetooth has applications (like Basic Print) that could be used to send
video stills for display. 802.11 and 802.3 (Ethernet) don't have any
application protocols.
I may make the telecon tonight - I have a very early meeting the following
morning (6am).
Cheers,
- Ira
On 10/29/07, Richard_Landau at dell.com <Richard_Landau at dell.com> wrote:
> 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>
--
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