Subject: [MIB-DOCTORS] Notification targets in 802.1ag MIB module (24 dec 2006)

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 11 Jan 2007 16:27:20 +0100

So based on the comments we've seen, it seem that they don't
need ANY target info in their MEP table. They can in fact just
use the RFC3413 MIB modules.

However, if for different MEPs they want different targets,
then they do require that (at deployment time) an operator/user
does specify the various filters ro filter on NOTIFICATYON-TYPE
(i.e. the value of snmpTrapOID.0) and the included OBJECT
dot1agCfmMepHighestPrDefect in order to determine those different 
targets. 

I guess that is what we intended with RFC3413. But I must admit that
this makes it quite complex to deploy. 

If they want to use just a tagValue (in their own MEP table) for 
the destination selection, then they are bypassing the snmpNotifyTable
I think, and so they are still not in-line with standard notification
target selection mechnisms that we defined.

So what to tell them?

Bert

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: zaterdag 30 december 2006 2:05
> To: MIB Doctors \\\(E-mail\\\)
> Subject: Re: [MIB-DOCTORS] RE: 
> useofTransportDomain/Address(RFC3419)vsTDomain/TAddres s (RFC2579)
> 
> Hi -
> 
> I'm missing something here.  Since they're already defining 
> OIDs for the other notification transport mechanisms, 
> wouldn't it be simpler to just use those values in 
> snmpTargetAddrTDomain?
> Even if they're not really SNMP, one could use "enterprise" 
> (IEEE) allocated values for snmpTargetParamsMPModel and 
> snmpTargetParamsSecurityModel  to identify whatever protocol 
> they'd like to use.
> 
> That way the access control and configuration would be 
> consistent, and no additional object types would be needed except as a
> (sparse) augmentation of the snmpTargetParamsTable in cases 
> where that transport needed parameters with semantics 
> different from those already available there.
> 
> Randy
> 
> 
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mib-doctors
> 

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 11 Jan 2007 11:14:49 -0500

Hi,

I suggest you tell them that operators currently need to configure the
RFC3413 tables for SNMPv3 notifications.

We found out from USM that operators become VERY unhappy when a new
standard forces operators to have to do significant **additional**
configuration to gain little or not additional benefit. Operators MUCH
prefer that new standards leverage existing standard infrastructures.

If 802.1ag uses the RFC3413 tables as the tables were designed to be
used, that will be easier for operators to deploy.

For those of us who have not been following 802.1ag, why do they want
different targets for different MEPs? What is a MEP? What criteria are
critical in selecting the MEP-target mappings?

Is having different targets a must-have feature of 802.1ag, or a
nice-to-have feature? Would it be viable, and simpler, for most
operators to NOT have different targets for different MEPs? Is the
complex filtering only required for operators who CHOOSE to have a
complex setup, but not required for those who prefer a simpler setup?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Thursday, January 11, 2007 10:27 AM
> To: Randy Presuhn; [email-masked]
> Cc: MIB Doctors
> Subject: [MIB-DOCTORS] Notification targets in 802.1ag MIB 
> module (24 dec2006)
>

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 11 Jan 2007 11:03:30 -0800 (PST)

HI,

My interpretation of the IEEE document is that they wanted to
allow a device to be
  1) owned by one providor, say A
  2) service provided by other providers, say B and C
  3) service used by other parties, say D, E, F, etc

So, they put in the mechanisms to "short cut" the SNMP admin
tables to deliver notifications to the providers, such as
B and C, so they can resolve issues.

This topic, "multiple operators sharing a single device
with separation and no info leakage", has been talked about
and attempted to be implemented in MIB modules using multiple
approaches over the years. There are examples in some of
the DISMAN MIB modules. My bottom line is that the solutions
have some success in limited operational domains, but are
difficult to understand and to configure. ((got to run,
but if you want more info, let me know and I'll follow up).

Regards,
/david t. perkins

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Jan 2007 11:25:58 -0800

Hi -

> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Cc: "MIB Doctors" <[email-masked]>
> Sent: Thursday, January 11, 2007 7:27 AM
> Subject: Notification targets in 802.1ag MIB module (24 dec 2006)
>
> I guess that is what we intended with RFC3413.

Agreed.

>  But I must admit that

I guess we have differing thresholds for "quite complex".

> target selection mechnisms that we defined.

My biggest concern is that access control is properly applied to
outgoing notifications and their payload.

I also think they should consider is the extent to which vendors
of management systems (and agent toolkits) will want to "special
case" these devices.  It might be simpler for someone building
a specialized system from scratch, but it offers only additional
work and complexity for someone working from an existing code base.

Presumably there has been some cost-benefit analysis of doing
notifications differently from the standard...  If they've done that
analysis, and come to the conclusion that this approach makes sense
for their products and their market, we have no business standing in
their way.

My $0.02.

Randy

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 12 Jan 2007 00:02:53 +0100

I believe that David Perkins interpretation here is correct.

And... yep, there are situations where the complex filtering
is probably not needed. As you may have seen, there are 3 possible
FaultAlarmDestinations. If the lowest level says "notspecified",
then the destination from the level above is used and so on.

I's expect that 2 levels will probably be used. The 3rd level,
is probably not used that much.

Now, let us see if we can suggest how the RFC3413 MIB tables need 
to be configured if we want 3 levels. I am going to try.... but pls
check, because I am not so sure I get it right.

We have 3 levels for which different destinations may need to
be specified:

1. dot1agCfmMdFaultAlarm Destination
   let us say we have 2 MD (maintenance domains)
   index is unsigned32, so let us assume index values 1 and 2
2. dot1agCfmMaFaultAlarm Destination
   let us say we have 2 MA (maintenance associations) per MD
   index is unsigned32, so let us assume index values 1 and 2
3. dot1agCfmMepFaultAlarm Destination
   let us say we have 2 MEP (Maintenance Association End Points) per MA
   index is unsigned32, so let us assume index values 1 and 2

A notification is defind as follows:

  dot1agCfmFaultAlarm  NOTIFICATION-TYPE    -- OID: 1.0.8802.1.1.3.0.1 
                                            -- 8 subIDs for filtermask
    OBJECTS { dot1agCfmMepHighestPrDefect } -- OID:
1.0.8802.1.1.3.1.7.1.1.15
                                            -- 11 subIDs for filtermask

where the included object is INDEXed by 
     dot1agCfmMdIndex,
     dot1agCfmMaIndex,
     dot1agCfmMepIdentifier

So we need to create entries in the various tables in the 
SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB modules.

for now I am doing just entries for MD1 and MD2, assuming all
notifications
for MD1 need to go to 1 destination, and for MD2 to another. Pls check
if
I have it right sofar, before I punish my brain with more of this
complexity.

In the snmpTargetAddrTable:

      snmpTargetAddrName        = "AlarmFaultDest1"      (index)
      snmpTargetAddrTDomain     = snmpIeee802Domain
      snmpTargetAddrTAddress    = MAC address for Destination 1
      snmpTargetAddrTimeout     = 1500
      snmpTargetAddrRetryCount  = 3
      snmpTargetAddrTagList     = "MD1Dest"
      snmpTargetAddrParams      = "MD1owner"
      snmpTargetAddrStorageType = 'nonVolatile'
      snmpTargetAddrRowStatus   = 'active'

      snmpTargetAddrName        = "AlarmFaultDest2"      (index)
      snmpTargetAddrTDomain     = SnmpUDPAddress
      snmpTargetAddrTAddress    = IPv4 address and port for Destination
2
      snmpTargetAddrTimeout     = 1500
      snmpTargetAddrRetryCount  = 3
      snmpTargetAddrTagList     = "MD2Dest"
      snmpTargetAddrParams      = "MD2owner"
      snmpTargetAddrStorageType = 'nonVolatile'
      snmpTargetAddrRowStatus   = 'active'

In the snmpTargetParamsTable:

      snmpTargetParamsName           = "MD1owner"        (index)
      snmpTargetParamsMPModel        = 3  -- SNMPv3
      snmpTargetParamsSecurityModel  = 3 -- User-Based Security Model
      snmpTargetParamsSecurityName   = "MD1ownerUserName"     
      snmpTargetParamsSecurityLevel  = 2 -- authNoPriv
      snmpTargetParamsStorageType    = 'nonVolatile'
      snmpTargetParamsRowStatus      = 'active'

      snmpTargetParamsName           = "MD2owner"        (index)
      snmpTargetParamsMPModel        = 3  -- SNMPv3
      snmpTargetParamsSecurityModel  = 3 -- User-Based Security Model
      snmpTargetParamsSecurityName   = "MD2ownerUserName"     
      snmpTargetParamsSecurityLevel  = 2 -- authNoPriv
      snmpTargetParamsStorageType    = 'nonVolatile'
      snmpTargetParamsRowStatus      = 'active'

In the snmpNotifyTable:

      snmpNotifyName         = "Name1"       (index)
      snmpNotifyTag          = "MDDest1"
      snmpNotifyType         = 'inform'
      snmpNotifyStorageType  = 'nonvolatile'
      snmpNotifyRowStatus    = 'active' 

      snmpNotifyName         = "Name2"        (index) 
      snmpNotifyTag          = "MDDest2"
      snmpNotifyType         = 'inform'
      snmpNotifyStorageType  = 'nonvolatile'
      snmpNotifyRowStatus    = 'active' 

And some entries in the snmpNotifyFilterProfileTable:

       snmpTargetParamsName             = "MD1owner"   (index)
       snmpNotifyFilterProfileName      = "MD1profile"
       snmpNotifyFilterProfileStorType  = 'nonvolatile'
       snmpNotifyFilterProfileRowStatus = 'active'

       snmpTargetParamsName             = "MD2owner"   (index)
       snmpNotifyFilterProfileName      = "MD2profile"
       snmpNotifyFilterProfileStorType  = 'nonvolatile'
       snmpNotifyFilterProfileRowStatus = 'active'

And some entries in the snmpNotifyFilterTable:

   -- for MD 1
       snmpNotifyFilterProfileName      = "MD1profile" (index)
       snmpNotifyFilterSubtree          = dot1agCfmFaultAlarm  (index)  
       snmpNotifyFilterMask             = 0x'FF'   -- filter on whole 
                                                   -- NOTIFICATION-TYPE
OID
       snmpNotifyFilterType             = 'include'
       snmpNotifyFilterStorageType      = 'nonvolatile'
       snmpNotifyFilterRowStatus        = 'active'
  
       snmpNotifyFilterProfileName      = "MD1profile" (index)
       snmpNotifyFilterSubtree          = dot1agCfmMepHighestPrDefect
(index)  
       snmpNotifyFilterMask             = 0x'FFF0' -- filter 12 subIDs
of OID 
                                                   -- any index other
than (MD) 1.
       snmpNotifyFilterType             = 'exclude'
       snmpNotifyFilterStorageType      = 'nonvolatile'
       snmpNotifyFilterRowStatus        = 'active'

       snmpNotifyFilterProfileName      = "MD1profile" (index)
       snmpNotifyFilterSubtree          = dot1agCfmMepHighestPrDefect.1
(index)  
       snmpNotifyFilterMask             = 0x'FFF8'  -- filter 12 subIDs
of OID
                                                    -- index (MD) 1.
       snmpNotifyFilterType             = 'include'
       snmpNotifyFilterStorageType      = 'nonvolatile'
       snmpNotifyFilterRowStatus        = 'active'

   -- for MD 2
       snmpNotifyFilterProfileName      = "MD2profile" (index)
       snmpNotifyFilterSubtree          = dot1agCfmFaultAlarm  (index)  
       snmpNotifyFilterMask             = 0x'FF'   -- filter on whole 
                                                   -- NOTIFICATION-TYPE
OID
       snmpNotifyFilterType             = 'include'
       snmpNotifyFilterStorageType      = 'nonvolatile'
       snmpNotifyFilterRowStatus        = 'active'
  
       snmpNotifyFilterProfileName      = "MD2profile" (index)
       snmpNotifyFilterSubtree          = dot1agCfmMepHighestPrDefect
(index)  
       snmpNotifyFilterMask             = 0x'FFF0' -- filter 12 subIDs
of OID 
                                                   -- any index other
than (MD) 2.
       snmpNotifyFilterType             = 'exclude'
       snmpNotifyFilterStorageType      = 'nonvolatile'
       snmpNotifyFilterRowStatus        = 'active'

       snmpNotifyFilterProfileName      = "MD2profile" (index)
       snmpNotifyFilterSubtree          = dot1agCfmMepHighestPrDefect.2
(index)  
       snmpNotifyFilterMask             = 0x'FFF8'  -- filter 12 subIDs
of OID
                                                    -- index (MD) 2.
       snmpNotifyFilterType             = 'include'
       snmpNotifyFilterStorageType      = 'nonvolatile'
       snmpNotifyFilterRowStatus        = 'active'

If people wanted to not specify specific destination at the MA level or
the
MEP level, then the above would take care of it all.

This already looks quite complex to me... that is for new
users/operators.
But I guess that is what we have done to them by STD62 :-(
If I have it correct sofar, then I will try the next level at MA and MEP
and see if I can do

- 3rd destination for MA1 (for all MEPs, that is no entries per MEP)
- 4th destination for MA2 (for MEPs without entry, I'll omit an entry
for MEP 1)
- 5th destination for MEP 2.

Bert
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: donderdag 11 januari 2007 20:04
> To: David B Harrington
> Cc: Wijnen, Bert (Bert); 'Randy Presuhn'; 'MIB Doctors'
> Subject: RE: [MIB-DOCTORS] Notification targets in 802.1ag 
> MIB module (24 dec2006)
> 
> HI,
> 
> tables to deliver notifications to the providers, such as B 
> and C, so they can resolve issues.
> 
> This topic, "multiple operators sharing a single device with 
> separation and no info leakage", has been talked about and 
> attempted to be implemented in MIB modules using multiple 
> approaches over the years. There are examples in some of the 
> DISMAN MIB modules. My bottom line is that the solutions have 
> some success in limited operational domains, but are 
> difficult to understand and to configure. ((got to run, but 
> if you want more info, let me know and I'll follow up).
> 
> Regards,
> /david t. perkins
> 
> module (24 
> >> dec2006)
> >> So based on the comments we've seen, it seem that they 
> don't need ANY 
> >> target info in their MEP table. They can in fact just use 
> the RFC3413 
> >> MIB modules.
> >>
> >> However, if for different MEPs they want different 
> targets, then they 
> >> do require that (at deployment time) an operator/user does specify 
> >> the various filters ro filter on NOTIFICATYON-TYPE (i.e. 
> the value of 
> >> snmpTrapOID.0) and the included OBJECT 
> dot1agCfmMepHighestPrDefect in 
> >> order to determine those different targets.
> >>
> >> If they want to use just a tagValue (in their own MEP 
> table) for the 
> >> destination selection, then they are bypassing the
> > snmpNotifyTable
> >>> I'm missing something here.  Since they're already 
> defining OIDs for 
> >>> the other notification transport mechanisms, wouldn't it 
> be simpler 
> >>> to just use those values in snmpTargetAddrTDomain?
> >>> snmpTargetParamsSecurityModel  to identify whatever 
> protocol they'd 
> >>> like to use.
> >>>
> consistent, 
> >>> and no additional object types would be needed
> >> except as a
> >>> (sparse) augmentation of the snmpTargetParamsTable in cases where 
> >>> that transport needed parameters with semantics different 
> from those 
> >>> already available there.
> >>>
> >>> Randy
> >>>
> >>>
> >>>

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 11 Jan 2007 19:00:28 -0500

Hi,

I haven't worked through your table configs, and have not studied the
802.1ag MIB module, but I wonder if you're approaching the problem the
wrong way by filtering on sub-oids rather than using the corresponding
SNMPv3 concepts.

Are you using different security names for the different principals?
Are you using VACM to specify groups of principals (i.e. same
company)?
Are you using contexts to separate different sets of data (e.g. by
company)?
Are you using VACM to determine what data each principal can see?
These SNMPv3 features can/should be used to determine which
notifications are allowed to be sent to which principals.
	
My impression is you are trying to put everything together in one big
table in one big context, and then using sub-oids to filter the data
into "associations" rather than using SNMPv3 contextNames to separate
the data by its association, and to apply access control by filtering
on sub-oids rather than using securitynames and VACM to provide access
control.

I think that using the existing features of SNMPv3 to handle different
aspects of the problem might be less complex than trying to use the
802.1ag MIB module and the notification tables to duplicate those
features. It also might make it easier for the operators to understand
what they are configuring, since they would config access controls
using the SNMP access control feature rather than an 802.1ag-specific
access control design.

dbh

> Sent: Thursday, January 11, 2007 6:03 PM
> To: David T. Perkins; Randy Presuhn; David B Harrington
> Cc: MIB Doctors
>                                                    -- 
> NOTIFICATION-TYPE
>                                                    -- any index
other
>                                                    -- 
> NOTIFICATION-TYPE
>                                                    -- any index
other

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 12 Jan 2007 12:54:59 +0100

David, thans for your reaction.
It is not very helpful yet.
Let me respond to your questions/suggestions inline: 

> From: David B Harrington [mailto:[email-masked]] 
> Sent: vrijdag 12 januari 2007 1:00
> To: Wijnen, Bert (Bert); 'David T. Perkins'; 'Randy Presuhn'
> Cc: 'MIB Doctors'
> I haven't worked through your table configs, and have not 
> studied the 802.1ag MIB module, but I wonder if you're 
> approaching the problem the wrong way by filtering on 
> sub-oids rather than using the corresponding
> SNMPv3 concepts.
> 

Well, subOIDs seems to be the only handle that I have in the CFM MIB.
If you want the compleet CFM MIB changed in order to do filetring
differntly, then we can forget it, because I do not believe that
802.1ag will enterntain that idea.

> Are you using different security names for the different principals?

yes, I will. In my snmpTargetAddrTable I already have MD1ownerUserName 
and MD2ownerUserName as 2 different principals. One for each domain.
there will be more once I add MAs and MEPs

> Are you using VACM to specify groups of principals (i.e. same 

Just for notification target selection, I think that is irrelevant,
but for access control, yes that would be done. I am not sure
I need to show those as well.

> Are you using contexts to separate different sets of data 
> (e.g. by company)?

Dan and I have been discussing the use of contextName for different
companies. It seems extremely difficult to describe how the contextName
gets (and keeps) linked to the proper table entries, because ifIndex
can change, and entries in the ifTable are part of this whole set
of entries that can be monitored/controlled by a specific company.

I then tried to find out from a few implementators how easy they
would be able to deal with the idea of using contexts (based
on their SNMP toolkits and implementations). The answer was not
very positive. So I have basically given up on the idea of using
contextNames. If you want to go spend many days to try and define
how they could use it, then convince them to make the changes...
Using the OIDs in view-based access control will not be easy
eaither, but... such is life.

> Are you using VACM to determine what data each principal can see?

I am not specifically, but that of course also needs to be done.
Do you think though that that is an easier (and more logical) way
to determine where specific alarms/notifications are going to be 
send to? Does that means you would confire target and notify MIB
modules such that all notifications go to all places
and that based on access control they would be filtered out
as to where they will actually be able to go?

Mmm... I guess that could sort of work, but I doubt that with that
I can re-create the hierarchy that they have defined right now.
At least I don't see yet how I can do that. Any suggestions/hints?

> notifications are allowed to be sent to which principals.

I understand how that part wokrs yes, but I can't see how I can
represent the hierarachical approach they now have.

> My impression is you are trying to put everything together in 
> one big table in one big context, and then using sub-oids to 
> filter the data into "associations" rather than using SNMPv3 
> contextNames to separate the data by its association, and to 
> apply access control by filtering on sub-oids rather than 
> using securitynames and VACM to provide access control.
> 

See my story about contextNames above.
And yep, using the subOID filtering for me seems the only way
I can recreate that hierarchical notification-destination
mechanism. I do not see how I can create that with just VACM
entries. But... my mind is just small. Pls hint me in the
right direction.

> I think that using the existing features of SNMPv3 to handle 
> different aspects of the problem might be less complex than 
> trying to use the 802.1ag MIB module and the notification 
> tables to duplicate those features. It also might make it 
> easier for the operators to understand what they are 
> configuring, since they would config access controls using 
> the SNMP access control feature rather than an 
> 802.1ag-specific access control design.
> 

I think we agree (Thanks to Perkins) that indeed they should
not setup their own tables. Wow, what a mistake I made there to
not have noticed that earlier. Good that we caught it just in time.

But I think we need a good example of how they can do what they
want to do in order to convince them (at this late point in their
process) to drop those objects from their MIB module.
So pls help me.

Bert

> MIB module 
> > (24 dec2006)
> > And... yep, there are situations where the complex filtering is 
> > probably not needed. As you may have seen, there are 3 possible 
> > FaultAlarmDestinations. If the lowest level says 
> "notspecified", then 
> > the destination from the level above is used and so on.
> > 
> > I's expect that 2 levels will probably be used. The 3rd level, is 
> > probably not used that much.
> > 
> > Now, let us see if we can suggest how the RFC3413 MIB 
> tables need to 
> > be configured if we want 3 levels. I am going to try.... but pls 
> > We have 3 levels for which different destinations may need to be 
> > specified:
> > 
> >    index is unsigned32, so let us assume index values 1 and 2 2. 
> > dot1agCfmMaFaultAlarm Destination
> >    index is unsigned32, so let us assume index values 1 and 2 3. 
> > dot1agCfmMepFaultAlarm Destination
> > notifications for MD1 need to go to 1 destination, and for MD2 to 
> > another. Pls
> check
> > if
> > NOTIFICATION-TYPE OID
> > NOTIFICATION-TYPE OID
> > If people wanted to not specify specific destination at the 
> MA level 
> > or the MEP level, then the above would take care of it all.
> > 
> If I have 
> > it correct sofar, then I will try the next level at MA and 
> MEP and see 
> > if I can do
> > 
> > > Subject: RE: [MIB-DOCTORS] Notification targets in 802.1ag MIB 
> > > module (24 dec2006)
> > > 
> > > HI,
> > > 
> > > My interpretation of the IEEE document is that they 
> wanted to allow 
> > > a device to be
> > > So, they put in the mechanisms to "short cut" the SNMP 
> admin tables 
> > > to deliver notifications to the providers, such as B and 
> C, so they 
> > > can resolve issues.
> > > 
> > > separation and no info leakage", has been talked about 
> and attempted 
> > > to be implemented in MIB modules using multiple 
> approaches over the 
> > > years. There are examples in some of the DISMAN MIB modules. My 
> > > bottom line is that the solutions have some success in limited 
> > > operational domains, but are difficult to understand and to 
> > > configure. ((got to run, but if you want more info, let 
> me know and 
> > > I'll follow up).
> > > 
> > > Regards,
> > > /david t. perkins
> > >

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 12 Jan 2007 16:46:31 -0800

Hi - 

> From: "Wijnen, Bert (Bert)" <[email-masked]>
...
> Sent: Thursday, January 11, 2007 3:02 PM
> Subject: RE: [MIB-DOCTORS] Notification targets in 802.1ag MIB module (24 dec2006)
...

> In the snmpTargetAddrTable:

Look ok.

...
> In the snmpTargetParamsTable:

Looks ok.

...
> In the snmpNotifyTable:

Looks Ok.

...
> And some entries in the snmpNotifyFilterProfileTable:

Looks ok.

...
> And some entries in the snmpNotifyFilterTable:
...

Here I think you made a few more entries than necessary -
I don't see why any of the "exclude" entries were needed.
Am I missing something?

Randy

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Sun, 14 Jan 2007 12:53:16 +0100

Thanks for the review/checks Randy.

Inline (at the end) 

> Sent: zaterdag 13 januari 2007 1:47
> To: MIB Doctors
> Subject: Re: [MIB-DOCTORS] Notification targets in 802.1ag 
> MIB module (24dec2006)
> 
> Hi - 
> 
> Here I think you made a few more entries than necessary - I 
> don't see why any of the "exclude" entries were needed.
> Am I missing something?
> 

I did that to ensure that no alarms for Mdomain 1 would go to
any other domain. They are only supposed to go to the domain1
owner. Does it make sense then? Or do you see a better way to 
achieve that?

Bert

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 14 Jan 2007 16:15:58 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>; "MIB Doctors" <[email-masked]>
> Sent: Sunday, January 14, 2007 3:53 AM
> Subject: RE: [MIB-DOCTORS] Notification targets in 802.1ag MIB module (24dec2006)
...
> owner. Does it make sense then? Or do you see a better way to 

In a word: VACM.  :-)

Randy