Subject: RE: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-m ib-15.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 18:15:01 -0400

Hi

The following is the proposed resolution to Randy-59  Assuming no objection,
this item will be considered closed conditional on the proposed edit being
done.

In the description of alarmActiveContextName replace

          "The name of the SNMP MIB context from which the alarm came.
          For SNMPv1 alarms this is the community string from the Trap.
          Note that care needs to be taken when selecting community
          strings to ensure that these can be represented as a
          well-formed SnmpAdminString.

          If the alarm's source SNMP engine is known not to support
          multiple contexts, this object is a zero length string."

With

          "The name of the SNMP MIB context from which the alarm came.
          For SNMPv1 alarms this is the community string from the Trap.
          Note that care MUST be taken when selecting community
          strings to ensure that these can be represented as a
          well-formed SnmpAdminString. Community or Context names
          that are not well-formed SnmpAdminStrings will be mapped
          to zero length strings.

          If the alarm's source SNMP engine is known not to support
          multiple contexts, this object is a zero length string."

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Thursday, October 02, 2003 4:12 PM
To: Disman (E-mail)
Subject: Re: [Disman] alarmActiveContextName in
draft-ietf-disman-alarm-mib-15.txt

Hi -

As technical contributor...

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "Disman (E-mail)" 
> <[email-masked]>
> Sent: Thursday, October 02, 2003 10:22 AM
> Subject: RE: [Disman] alarmActiveContextName in
draft-ietf-disman-alarm-mib-15.txt

...
> > still doesn't tell us what a system is supposed to do when its 
> > handling a trap with a community string of, say, 0xff.
>
> I was meaning that a NULL string is being added in this case. Yeah, 
> it's more than just a MUST.

If that's what's intended, it should say so.
I'm not sure whether it's the best possible solution,
but this is a corner case that's probably not worth over-engineering.

...
> I am not familiar enough with AgentX or SMUX, but how do they deal 
> with notifications received from sub-agents that need to be forwarded? 
> This should not be different? Also, was not SMUX a pre-SNMPv2 beast?

Yeah, let's focus on AgentX; SMUX is a red herring here.
For AgentX, the subagent supplies the context name as
part of the notification.  The master agent need never have heard of it
before, though if VACM is in use an entry with a zero-length
vacmAccessContextPrefix and vacmAccessContextMatch equal to prefix(2) would
be needed to let these things get to the wire.

The important thing is that the information is supplied by the subagent, and
the master agent doesn't know in advance how many different contexts it
might see in these notifications.

Furthermore, RFC 2741 is (unfortunately) explicit in section 6.1.1 in saying
that

   AgentX provides a mechanism for transmitting a context specification
   within relevant PDUs, but does not place any constraints on the
   content of that specification.
...
   context.  The context is represented as an Octet String.  There are
   no constraints on its length or contents.

I'm willing to treat non-SnmpAdminString contexts from subagents as a
pathological case. Lumping them in with the goofy community strings and
mapping them to a zero-length alarmActiveContextName. (which would be
indistinguishable from the default context) is probably as good a solution
as any.

Sooo, back to the original problem:

I think the first paragraph should state that community or context values
that violate the SYNTAX are to be mapped to a zero-length string. I think
the second paragraph should be MAY rather than MUST.

Randy