Subject: [Fwd: Re: [IETFMIBS] MIB draft review request]

From: "Glenn M. Keeni" <[email-masked]>
Date: Wed, 21 Feb 2007 10:44:06 +0900

Resending after subscribing to the list.

Glenn

-------- Original Message --------
Subject: Re: [IETFMIBS] MIB draft review request
Date: Tue, 20 Feb 2007 11:46:34 +0900
From: Glenn M. Keeni <[email-masked]>
To: Hamid Mukhtar <[email-masked]>
CC: Randy Presuhn <[email-masked]>,  [email-masked]
References:
<[email-masked]>
<[email-masked]>

Hi,
     The aggregation MIB is generic and experimental. Implementing
such a generic MIB on a severely resource constrained 6lowpan device
is not recommended and probably not practical. In fact, there is no
guarantee that even a single MO-val pair will fit in the 33 octets
(think of a case where the value itself is longer than 33 octets).
     If you are thinking of a scenario where you want multiple pieces
of "vital information" to fit in 33 octets, you MAY need to think of
specially crafted MOs that contain the pieces of "vital information"
in a predefined format/encoding and fit in 33 octets along with the
SNMP headers. That may not be easy.

Glenn

Hamid Mukhtar wrote:
> Hi
> 
> On 2/19/07, *Randy Presuhn* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi -
> 
>      >From: Hamid Mukhtar <[email-masked]
>     <mailto:[email-masked]> >
>      >Sent: Feb 19, 2007 5:55 AM
>      >To: [email-masked] <mailto:[email-masked]>
>      >Cc: Soohong Daniel Park <[email-masked]
>     <mailto:[email-masked]> >, Soohong Daniel Park
>     <[email-masked] <mailto:[email-masked]>>,
>     [email-masked] <mailto:[email-masked]>
>      >Subject: Re: [IETFMIBS] MIB draft review request
>     ...
>      >For packet SNMP compression IETF already defined aggregation MIB (rfc
>      >4498). I think we can recommend the use of aggregation MIB for
>     6lowpan in
>      >the draft.
>     ...
> 
>     RFC 4498 is experimental, not standards track, and was an
>     individual contribution, not an IETF product.  It does not address
>     the general question of reducing the size of an arbitrary SNMP
>     message, but rather provides a way to set up and invoke
>     "canned" operations, such as a Get of several object instances.
> 
>     The analysis of SNMPv3 vs SNMPv1 and SNMPv2c message
>     sizes has been done before.  Is it *really* an issue for this
>     technology?
> 
>  
> The problem is that there are only 33 octets available for 
> application data in 6lowpan networks so there must be a compression 
> mechanism for SNMP packets if we want to support SNMP over 6lowpan.
> so thats why we are looking for some standard mechanisms to support 
> compression or aggregation of SNMP data.
> 
>     Randy
> 
> 
>     _______________________________________________
>     IETFMIBS mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www1.ietf.org/mailman/listinfo/ietfmibs
> 
>  
> Hamid
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IETFMIBS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietfmibs

_______________________________________________
IETFMIBS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietfmibs