Subject: [IETFMIBS] Message Encoding for SNMPv3

From: Hamid Mukhtar <[email-masked]>
Date: Thu, 26 Feb 2009 14:54:43 +0900

Dear all,

I had the following query about usage of BER for SNMPv3.

Is it MANDATORY encoding for all SNMPv3 messages or it is a
RECOMMENDED encoding.

In the latter case what other options do we have to encode the SNMPv3 messages.
However if it is mandatory, can SNMPv3 proxy-mib be used to translate
between different encodings (Additional parsing functionality at
target's Message processing subsystem assumed) or SNMPv3 messages MUST
use BER for e2e transmissions.

Regards,
Hamid

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 26 Feb 2009 06:16:14 -0800

>>>>> On Thu, 26 Feb 2009 14:54:43 +0900, Hamid Mukhtar <[email-masked]> said:

HM> Is it MANDATORY encoding for all SNMPv3 messages or it is a
HM> RECOMMENDED encoding.

It's mandatory.  Existing software only understands BER based encodes
(there are some plugins to some products to do XML as well, but that's a
completely different ball-park)
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 26 Feb 2009 10:01:09 -0800

Hi -

> From: "Hamid Mukhtar" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, February 25, 2009 9:54 PM
> Subject: [IETFMIBS] Message Encoding for SNMPv3
...
> Is it MANDATORY encoding for all SNMPv3 messages or it is a

For the transport mappings defined in RFC 3417 it is mandatory.

> In the latter case what other options do we have to encode the SNMPv3 messages.

None, unless/until someone develops & standardizes a new transport mapping.
I don't think that's terribly likely, since most energy these days is going to netconf.

> between different encodings

You probably already know this, but to be absolutely clear,
the MIB itself doesn't do any translation.  Translation should be a
consequence of the underlying SNMP engine mapping the wire
encoding to a common internal representation.

> (Additional parsing functionality at

The question is ill-formed - Proxy (by definition) involves TWO end-to-end
transmissions - At the protocol level, the proxy is an endpoint from the
perspective of both the managing and the managed systems.  Furthermore,
the proxy forwarder (as defined in RFC 3413) uses a narrow sense
of the term proxy - please go to that document for details.

Randy

---

From: Hamid Mukhtar <[email-masked]>
Date: Fri, 27 Feb 2009 10:08:36 +0900

Hi Randy,

> For the transport mappings defined in RFC 3417 it is mandatory.

thanks for clarifying that.

> of the term proxy - please go to that document for details.

Just for my knowledge, Is the use of proxy-forwarder applications
restricted to forwarding the four basic types only or they can be used
for other proxy related applications too.

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 26 Feb 2009 21:24:39 -0800

Hi -

> From: "Hamid Mukhtar" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, February 26, 2009 5:08 PM
> Subject: Re: [IETFMIBS] Message Encoding for SNMPv3
...
> for other proxy related applications too.

I'm not sure what you mean by "the four basic types".

Randy

---

From: Hamid Mukhtar <[email-masked]>
Date: Fri, 27 Feb 2009 16:55:14 +0900

> I'm not sure what you mean by "the four basic types".

RFC 3413 in its section 3.5 identifies four basic types of proxy
forwarder applications. You specified that the proxy forwarder (as
defined in RFC 3413) uses a "narrow sense" of the term proxy. For my
understanding I just need to clarify what you mean by narrow sense. Do
you mean that the only translation a proxy forwarder can do as an
intermediate entity is between SNMP versions. Thus the SNMPv3 proxy
forwarders cannot be used to translate between SNMP and non-SNMP
protocols (for instance a protocol which uses XML instead of BER
encoding).

> Randy

Thanks for the help.

Regards,
Hamid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Feb 2009 09:16:05 +0100

On Fri, Feb 27, 2009 at 04:55:14PM +0900, Hamid Mukhtar wrote:
 
> forwarder applications. 

No. It talks about four basic types of messages (PDU classes). There
is only a single forwarder application as far as I can tell.

> You specified that the proxy forwarder (as defined in RFC 3413) uses
> a "narrow sense" of the term proxy. For my understanding I just need
> to clarify what you mean by narrow sense. Do you mean that the only
> translation a proxy forwarder can do as an intermediate entity is
> between SNMP versions. Thus the SNMPv3 proxy forwarders cannot be
> used to translate between SNMP and non-SNMP protocols (for instance
> a protocol which uses XML instead of BER encoding).

The encoding of messages is a property of the transports. A proxy
simply relays messages and does not know about their encoding. So in
order to change the encoding, you have to relay messages through a
different transport. In other words, once you have new transport with
a new encoding, everything else will be in place.

That said, I agree with those who believe establishing a new transport
for the sake of changing the encoding is a waste of efforts. But if
you want to dig further, you definately should look at the ISMS work,
in particular <draft-ietf-isms-tmsm-16.txt>.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 27 Feb 2009 11:35:50 -0800

Hi -

> Sent: Thursday, February 26, 2009 11:55 PM

No, it does not.  Section 3.5 describes the handling of four message
types to be handled by a proxy application.

>  You specified that the proxy forwarder (as

See RFC 3413 section 1.5.  This paragraph sums it up:

   To avoid such confusion, this document uses the term "proxy" with a
   much more tightly defined meaning.  The term "proxy" is used in this
   document to refer to a proxy forwarder application which forwards
   either SNMP messages without regard for what managed objects are
   contained within those messages.  This definition is most closely
   related to the first definition above.  Note, however, that in the
   SNMP architecture [RFC3411], a proxy forwarder is actually an
   application, and need not be associated with what is traditionally
   thought of as an SNMP agent.

Randy