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

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

> > 59) alarmActiveContextName: this is defined to be an 
> SnmpAdminString.
> >     This is fine for the case where its value is a context name.
> >     However, in the case where it is a community, provision needs
> >     to be made for the possibility that the community name would not
> >     be a well-formed SnmpAdminString.  (for example, 0xFF would be
> >     a legal community, but would violate the rules for UTF-8.)
> >     ditto alarmClearContextName
> ...
> 
> I think this probalem hasn't been addressed.
> The current text says:
> 
>    alarmClearContextName OBJECT-TYPE
>       SYNTAX      SnmpAdminString (SIZE(0..32))
>       MAX-ACCESS  read-only
>       STATUS      current
>       DESCRIPTION
>           "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.
> 
> 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.

---

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

See in-line. Regards, Dan

> > 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
> 
> 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,
> 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?

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Oct 2003 21:14:31 +0200

OK to me as well. Dan

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: 22 October, 2003 3:12 AM
> To: Disman (E-mail)
> Subject: Re: [Disman] alarmActiveContextName in 
> draft-ietf-disman-alarm-mib-15.txt
> 
> 
> Hi -
> 
> This looks fine to me.  I know that in the past there has 
> been concern about
> MIB objects that provide access to community strings, 
> insecure as they are.
> Perhaps we should add words to the security considerations 
> section explaining
> the (perceived) sensitivity of this object, perhaps saying 
> something like
> "Although the use of community strings in SNMPv1 is not 
> considered an effective
> means of providing security, security administrators SHOULD 
> consider whether
> the fact that alarmActiveContextName can reveal community 
> string values would
> make this object sensitive in their environment."  (I'm sure 
> someone can find
> better words!)
> 
> Randy
> 
> > From: "Sharon Chisholm" <[email-masked]>
> > To: "Disman (E-mail)" <[email-masked]>
> > Sent: Saturday, October 18, 2003 3:15 PM
> > Subject: RE: [Disman] alarmActiveContextName in 
> draft-ietf-disman-alarm-mib-15.txt
> >
> 
> > 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
> >
> >           For SNMPv1 alarms this is the community string 
> from the Trap.
> > With
> >           For SNMPv1 alarms this is the community string 
> from the Trap.
> >           Note that care MUST be taken when selecting community
> >           well-formed SnmpAdminString. Community or Context names
> >           that are not well-formed SnmpAdminStrings will be mapped
> >           to zero length strings.
> >
> > -----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
> >
> >
> >
> >
> 
> 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Oct 2003 21:14:31 +0200

OK to me as well. Dan