[Videomgmt] RE: Overall thoughts on a standard Video Management MIB

["Larry R. Walsh" <[e-mail]>]

Some thoughts on various topics (from one who has never participated in
a standards effort, but who has read a lot of SNMP/IETF standards):

-- Any "standard" MIB designed will probably not be exactly like any one
vendor's existing MIB. So everyone who wants to use the new standard
video management MIB will have to choose between just keeping their own
MIBs, or also implementing the new standard.
-- Other industries have standard MIBS, and vendors implementing agent
support for the standard MIB typically also have their own proprietary
MIBs & agents. EG The Standard Printer MIB and HP-specific Printer MIBs.
Similar examples exist for data base systems, and other industries.
-- I have also seen "experimental" standard MIBs appear in the OID-space
of specific vendors. (Personal opinion - not a great idea)
-- The Entity MIB is useful for modeling chassis types of architectures.
It models components such as the chassis, the slots, the boards, the
ports in a manner that would allow a very smart manager to make a
drawing. It also has extensive Textual Conventions that "name"
components. But the actual modelling of very specific objects (eg power
supplies, what voltages they support, the status of those voltages) is
the responsibility of vendors. The Entity MIB will "point" to those
modelling MIBs.
-- However the Entity MIB does not have Video-industry specific Textual
Convention definitions (nor should it).
-- Is there a need for a Video-Management-specific-entity-type MIB?
-- RFC's always have a well-written textual description of what this RFC
(and any associated MIB) intends to accomplish. EG, the problem to be
solved, the system to be modelled, why are we doing this. It might be
well be have an agreed-on strategy before we move to actual MIB design.
(I like Bob's idea of starting small at first.)
-- Defining Standard Textual Conventions for video management might be
useful.
-- And perhaps Standard OID-enumerations for component types.





> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Wednesday, September 28, 2005 9:10 AM
> To: [e-mail]
> Subject: Videomgmt Digest, Vol 1, Issue 4
> 
> 
> Send Videomgmt mailing list submissions to
> 	[e-mail]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/videomgmt
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
> 
> You can reach the person managing the list at
> 	[e-mail]
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Videomgmt digest..."
> 
> 
> Today's Topics:
> 
>    1. The initial proposal... (Tendolkar Mohit)
>    2. RE: The initial proposal... (Ray, Robert)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 27 Sep 2005 09:45:11 -0700
> From: "Tendolkar Mohit" <[e-mail]>
> Subject: [Videomgmt] The initial proposal...
> To: "Ray, Robert" <[e-mail]>, <[e-mail]>
> Message-ID:
> 	
> <[e-mail]>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Hi Ray,
> 
> Before we proceed to the MIB specific details, could you 
> please clarify whether PESA is willing to update portions of 
> its initial proposal to accommodate other existing IETF MIBs?
> 
> The reason I am asking this is based on previous experiences, 
> vendors wanted to "standardize" their MIB efforts "as is" 
> without allowing significant updates to their proposals based 
> on recommended or existing standards because it would "break" 
> their implementations already available on the market. I see 
> that the PESA MIBs have been drawn up starting from mid-2002, 
> so I reckon, there are products already supporting these MIB modules?
> 
> So before we spend the time and effort in drawing up a true 
> open MIB, it now becomes important to understand the stance 
> of the initial proposal. The PESA MIBs are certainly and 
> without doubt generic and truly useful MIBs as a starting 
> point, but given the usage of the other standardized MIBs 
> (ENTITY MIB, for instance) in conjunction with these modules 
> will imply certain structural changes to the proposed 
> modules. How strong is PESA on retaining the proposed MIB 
> modules "as is"?
> 
> Regards,
> 
> Mohit Tendolkar
> Thomson (Grass Valley)
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 27 Sep 2005 12:08:34 -0500
> From: "Ray, Robert" <[e-mail]>
> Subject: [Videomgmt] RE: The initial proposal...
> To: "Tendolkar Mohit" <[e-mail]>,
> 	<[e-mail]>
> Message-ID:
> 	<[e-mail]>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Hi Mohit.
> 
> Responses inline...
> 
> Regards,
> Bob Ray
> 
> ---------------------------------------------------------------
> 
> From: Tendolkar Mohit [mailto:[e-mail]] 
> Sent: Tuesday, September 27, 2005 11:45 AM
> To: Ray, Robert; [e-mail]
> Subject: The initial proposal...
> 
> >Hi Ray,
> >
> >Before we proceed to the MIB specific details, could you please
> >clarify whether PESA is willing to update portions of its initial 
> >proposal to accommodate other existing IETF MIBs?
> 
> PESA is committed to this effort and hold no reservations about 
> revising our products to support these efforts.  As a 
> programmer, I do 
> like what I did (wrt the three MIBs) but am by no means 
> wedded to them. I welcome improvements and interoperability.  
> I believe our customers 
> would welcome that as well.  Even if it means starting from scratch.
> 
> >The reason I am asking this is based on previous experiences, vendors
> >wanted to "standardize" their MIB efforts "as is" without allowing 
> >significant updates to their proposals based on recommended 
> or existing
> 
> >standards because it would "break" their implementations already
> available 
> >on the market. I see that the PESA MIBs have been drawn up 
> starting for
> 
> >mid-2002, so I reckon, there are products already supporting 
> these MIB
> >modules?
> 
> Yes, PESA is shipping products that support the MIBs.  
> Technically, however, 
> We have no problem supporting multiple MIBs in one agent.  If 
> we (the list and possible working group) devise one or more 
> standardized MIBs which works
> 
> across multiple vendors, it would exist in a different branch 
> (as it would 
> have IANA-assigned identifiers, etc.).  We (PESA) would 
> simply add another 
> subtree to our agent (of course, there may be some 
> instrumentation details, 
> but that's how we programmers earn our keep!)
> 
> >So before we spend the time and effort in drawing up a true open MIB,
> >it now becomes important to understand the stance of the initial
> proposal. 
> >The PESA MIBs are certainly and without doubt generic and 
> truly useful
> MIBs,
> >but given the usage of the ENTITY MIB (for instance) in conjunction
> with 
> >these modules will imply certain structural changes to the proposed
> modules.
> >How strong is PESA on retaining the proposed MIB "as is"?
> 
> The stance is as I've said: the MIBs are simply placeholders, 
> a suggested 
> start, that could be reamed asunder by the advancements and 
> concerns of an 
> open working group.  And I would welcome such involvement.  
> Truly.  I value my good name (such as it is) too much to try 
> anything less.  Further, it would be 
> transparent to the IETF Area Directors and we would never get 
> anything done 
> anyway...
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Videomgmt mailing list
> [e-mail] https://www1.ietf.org/mailman/listinfo/videomgmt
> 
> 
> End of Videomgmt Digest, Vol 1, Issue 4
> ***************************************
> 


_______________________________________________
Videomgmt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/videomgmt