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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 Oct 2003 20:22:32 +0300

See in-line. Regards, Dan

> >
> > If an SNMPv1 trap had a community string with a value of 0xFF,
> > what value would the corresponding instance of this object have?
> > The alarm MIB implementation has no control over the community
> > strings it might encounter.
> >
> >           If the alarm's source SNMP engine is known not to support
> >           multiple contexts, this object is a zero length string."
> >       ::= { alarmClearEntry 6 }
> >
> >
> > Is this intended to be a MUST or a MAY?
> >
> > Randy
> 
> ...
> > The solution is to make the text crisper that community 
> strings can be represented. This means a couple of
> > MUSTs in the two places quoted by Randy.
> ...
> 
> I think this does not solve the problems.
> In the first case, adding a "MUST" to
> 
> >           "The name of the SNMP MIB context from which the 
> alarm came.
> >           For SNMPv1 traps 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.
> 
> 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.

> 
> In the second case,
> >           If the alarm's source SNMP engine is known not to support
> >           multiple contexts, this object is a zero length string."
> 
> how is an implementation supposed to know whether a given source
> doesn't support multiple contexts?  For example, in AgentX and
> SMUX protocols, there is no registration mechanism for notifications,
> so a master agent has no way of knowing in advance whether it will
> receive notifications from multiple contexts or not.
> 

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?

> Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 13:12:05 -0700

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

...
> 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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Oct 2003 13:12:05 -0700

Hi -

...

...

Randy