Subject: Re: [IETFMIBS] MIB draft review request

From: Randy Presuhn <[email-masked]>
Date: Mon, 19 Feb 2007 10:08:35 +0700 (GMT+07:00)

Hi -

>From: Hamid Mukhtar <[email-masked]>
>Sent: Feb 19, 2007 5:55 AM
>To: [email-masked]
>Cc: Soohong Daniel Park <[email-masked]>, Soohong Daniel Park <[email-masked]>, [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?

Randy

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

---

From: "Hamid Mukhtar" <[email-masked]>
Date: Mon, 19 Feb 2007 16:42:46 +0900

Hi

On 2/19/07, Randy Presuhn <[email-masked]> wrote:
> >Cc: Soohong Daniel Park <[email-masked]>, Soohong Daniel Park <
> [email-masked]>, [email-masked]

 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

Hamid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Feb 2007 10:03:55 +0100

> sizes has been done before.  Is it *really* an issue for this

The 6lowpan environment is severly size constrained. This can only
change with an update of the underlying 802.15.4 technology as far as
I understand things (or of course relying an some fragmentation and
reassembly in an environment which rather high failure probabilities).

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany