Subject: RE: [MIB-DOCTORS] RE: use of TransportDomain/Address (RFC3419)vsTDomain/TAddres s (RFC2579)

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 28 Dec 2006 17:10:16 +0200

Yes, it is available at
http://www.ieee802.org/1/files/private/ag-drafts/d7/802-1ag-d7-1.pdf. If
anybody lacks the user name and password, please let me or Bert know. 

There have been more mails explaining and suggesting proposals, I will
forward them separately. 

Dan

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Thursday, December 28, 2006 5:00 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Cc: 'MIB Doctors (E-mail)'
> Subject: RE: [MIB-DOCTORS] RE: use of TransportDomain/Address 
> (RFC3419)vsTDomain/TAddres s (RFC2579)
> 
> Is their design (e.g. mib module) available for MIB Doctor perusal? 
> Are they making the design SNMP-configurable?
> 
> I'm not really interested in reviewing the 802.1ag standard, 
> or the complete 802.1ag mib module, but if they have a better 
> solution for configuring SNMPv3 notifications, I would 
> certainly be interested in seeing their proposal.
> 
> Without seeing how they want to use addressing, it is 
> difficult to advise which is the best addressing approach.
> 
> dbh
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > Sent: Thursday, December 28, 2006 4:48 AM
> > To: [email-masked]
> > Cc: MIB Doctors (E-mail)
> > Subject: RE: [MIB-DOCTORS] RE: use of TransportDomain/Address 
> > (RFC3419)vsTDomain/TAddres s (RFC2579)
> > 
> > (a), (b) - yes, they would prefer to leave the design open for use 
> > with other protocols. Yet at this point SNMP is the only 
> game in town,
> but
> > this includes SNMP run directly over the 802 MAC layer
> > (c) - Notifications are being send by entities belonging to a 
> > hierarchy of entities in 802.1ag which reflect different 
> admin domains 
> > (owner
> of
> > the device, provider, customer). Notification target may not be 
> > defined for one level, and then the target is being 
> 'outsourced' from 
> > the
> next
> > level in the hierarchy. During the discussions with the 
> IEEE 802.1ag 
> > experts they may have found a way to model this in 3413, but it is 
> > judged to be too complex for a draft which is now being 
> prepared for 
> > Sponsor Ballot which is more or less equivalent with IETF LC.
> > 
> > Dan
> > 
> > 
> >  
> >  
> > 
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder [mailto:[email-masked]]
> > > Sent: Thursday, December 28, 2006 10:48 AM
> > > To: Romascanu, Dan (Dan)
> > > Cc: Wijnen, Bert (Bert); MIB Doctors (E-mail)
> > > Subject: Re: [MIB-DOCTORS] RE: use of TransportDomain/Address
> > > (RFC3419) vsTDomain/TAddres s (RFC2579)
> > > 
> > > On Thu, Dec 28, 2006 at 08:13:22AM +0200, Romascanu, Dan
> > (Dan) wrote:
> > > > I believe that the discussion in (3) is important and should be 
> > > > conducted maybe as part of the multiprotocol management
> framework 
> > > > discussions which we should have rather sooner than later
> > > in the area.
> > > > 
> > > > I would however not delay recommending (2) for the IEEE
> > 802.1ag MIB
> > > > work because 93) is not going to get resolved that soon,
> > > and 802.1ag
> > > > has a schedule to meet, of course while documenting the
> > > rationale and
> > > > the constraints involved with this solution.
> > > 
> > > Perhaps you can clarify the following:
> > > 
> > > (a) Does 802.1ag really want to address arbitrary management
> > >     interfaces?
> > > 
> > > (b) If yes, what specific protocols do they have in mind (or do
> they
> > >     really don't know)?
> > > 
> > > (c) If no, why does (1) not work.
> > > 
> > > I believe it is important to have a clear description of the 
> > > situation if you seek advice from MIB doctors. I suppose the 
> > > majority on this list is likely not as closely involved in IEEE 
> > > 802.1ag as you (and
> > > Bert) likely are.
> > > 
> > > /js
> > > 
> > > -- 
> > > Juergen Schoenwaelder		 {International|Jacobs} 
> > > University Bremen
> > > <http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 
> > > 28725 Bremen, Germany
> > > 
> > 
> > _______________________________________________
> > 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: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 28 Dec 2006 17:25:17 +0100

In additioon to the complete spec, here is the (ASCII) version of the
current 1ag (CFM) MIB module.

Pls do not further distribute. We got it (and access) in order to do
MIB doctor review. I think it helps to understand the TDOMAIN/TADDRESS
discussion.

Bert
> Sent: donderdag 28 december 2006 16:10
> To: David B Harrington; [email-masked]
> Cc: MIB Doctors (E-mail)
> Subject: RE: [MIB-DOCTORS] RE: use of 
> TransportDomain/Address(RFC3419)vsTDomain/TAddres s (RFC2579)
> 
> Yes, it is available at
> http://www.ieee802.org/1/files/private/ag-drafts/d7/802-1ag-d7
> -1.pdf. If anybody lacks the user name and password, please 
> let me or Bert know. 
> 
> There have been more mails explaining and suggesting 
> proposals, I will forward them separately. 
> 
> Dan
> 
> 
>  
>  
> 
> > I'm not really interested in reviewing the 802.1ag standard, or the 
> > complete 802.1ag mib module, but if they have a better solution for 
> > configuring SNMPv3 notifications, I would certainly be 
> interested in 
> > seeing their proposal.
> > 
> > Without seeing how they want to use addressing, it is difficult to 
> > advise which is the best addressing approach.
> > 
> > dbh
> >

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 28 Dec 2006 17:34:32 -0800 (PST)

HI,

I read through the MIB module in the email that Bert sent.
There are many issues that I have with it, but putting them
aside, here is what I see happening with respect to notifications.

The module contains a definition for a single notification,
which is dot1agCfmFaultAlarm (which contains the single
item dot1agCfmMepHighestPrDefect in its OBJECTS clause).
This notification is used to report a persistent defect
condition.

The table dot1agCfmMdTable defines "maintenance domains" (each
row in the table is one, and a "maintenance domain" the
network or the part of the network for which faults in
connectivity are to be managed.) Each row contains
the objects:
   dot1agCfmMdFaultAlarmDestDomain - has syntax of TransportDomain
       and specifies the interpretation of the value of object
       dot1agCfmMdFaulAlarmDestAddress
   dot1agCfmMdFaulAlarmDestAddress - has syntax of TransportAddress
       and determines the target(s) for "dot1agCfmFaultAlarm
       notifications".
The value for TransportDomain as defined in MIB module
TRANSPORT-ADDRESS-MIB found in RFC 3419 is an OID value
such as for IPv4 UDP, IPv4 TCP, etc.
The IEEE8021-CFM-MIB module includes definitions of two
additional OID values to be used as value for TransportDomain,
which are:
   dot1agNotSpecified - used to indicate that no notitication
      is to be sent and the value of associated address object
      (for example, dot1agCfmMdFaulAlarmDestAddress) is
      unused (and would normally have a zero length string
      value)
   dot1agTagList - used to indicate that the value of the
      associated address object (for example,
      dot1agCfmMdFaulAlarmDestAddress) is a list of
      tags (in the form as defined by TC SnmpTagList)
And also uses the following OID value defined in 
MIB moduleSNMP-IEEE802-TM-MIB:
   snmpIeee802Domain - used to indicate that the value of the
      associated address object (for example,
      dot1agCfmMdFaulAlarmDestAddress) is a MAC address

My interpretation is the following:

When an event occurs that matches the definition of the event
of notification dot1agCfmFaultAlarm, instead of using the
mechanisms as defined in RFC 3413 to determine the filtering
and delivery of a notification, this module says that
objects dot1agCfmMdFaultAlarmDestDomain and
dot1agCfmMdFaulAlarmDestAddress are to be used.
This is VERY problematic, since these objects
do NOT have enough info. Putting aside the case
when dot1agCfmMdFaultAlarmDestDomain has the
value dot1agTagList, the other cases are missing
the following info:
   1) notification type (trap or inform) - such as defined
      by object snmpNotifyType
   2) for informs, the timeout value - such as defined
      by object snmpTargetAddrTimeout
   3) for informs, the retry value - such as defined
      by object snmpTargetAddrRetryCount
   4) the message processing model type (such as SNMPv1, SNMPv2c,
      or SNMPv3) - such as defined by object snmpTargetParamsMPModel
   5) the security model type (such as community string, USM, or
      ISMS) - such as defined by object snmpTargetParamsSecurityModel
   6) the security name - such as defined by object
      snmpTargetParamsSecurityName
   7) the security level (type) - such as defined by object
      snmpTargetParamsSecurityLevel

When the value is dot1agTagList, the value of the associated
transport address is actually a tag list, and that list
determines the sending of the notification "according to
RFC 3413". Well, I don't know how to interpret that instruction.
Are the tag values used to select entries in table
snmpNotifyTable or in table snmpTargetAddrTable.

I've seen in other vendor MIB modules a similar attempt
to simplify the tables defined in RFC 3413 to manage the
sending of notifications. The above doesn't work, and it
didn't appear to me that the vendor approaches worked without
other simplifying assumptions.

So, I believe that what was done in the IEEE module is BROKEN
for managing the delivery of notifications, and I believe that
there are many other problems in the MIB module (which I came
across, but have not described).

Hopefully, this flawed model is not being replicated in
other MIB modules, but probably is since I doubt the authors
invented this approach!

Regards,
/david t. perkins

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 29 Dec 2006 15:47:16 +0100

Thanks for a check/review and your comments.

My responses inline 

> From: David T. Perkins [mailto:[email-masked]] 
> Sent: vrijdag 29 december 2006 2:35
> To: Wijnen, Bert (Bert)
> Cc: David B Harrington; [email-masked]; MIB 
> Doctors \(E-mail\)
> aside, 

I would be much better to list you issues instead of putting them
aside. But... if you do put them aside... pls do not blame any of 
us (who are involved in reviewing) for not having seen them.

> here is what I see happening with respect to notifications.
> 
> which is dot1agCfmFaultAlarm (which contains the single item 
> dot1agCfmMepHighestPrDefect in its OBJECTS clause).
> This notification is used to report a persistent defect condition.
> 

And what is the issue with that?

> The table dot1agCfmMdTable defines "maintenance domains" 
> (each row in the table is one, and a "maintenance domain" the 
> connectivity are to be managed.) Each row contains the objects:
> TRANSPORT-ADDRESS-MIB found in RFC 3419 is an OID value such 
> as for IPv4 UDP, IPv4 TCP, etc.

I assume that sofar you have no isse with the use of the OIDs?

> additional OID values to be used as value for 
> TransportDomain, which are:

This seems fine to me. It is very similar to zeroDotZero meaning
no alarm is to be generated.
Do you see a problem with this?

>       tags (in the form as defined by TC SnmpTagList)

That one is very new (was added right at the start of the X-mas
days) and I have not looked at it yet and what its implications
are. It might be strange, but I need to check it deeper before I
can comment.

> And also uses the following OID value defined in MIB 
> moduleSNMP-IEEE802-TM-MIB:
Is that a problem in itself?
I thought this was/is OK.
If not, pls explain.

> and delivery of a notification, this module says that objects 
> dot1agCfmMdFaultAlarmDestDomain and 
> This is VERY problematic, since these objects do NOT have 
> enough info. Putting aside the case when 
> dot1agCfmMdFaultAlarmDestDomain has the value dot1agTagList, 
> the other cases are missing the following info:

Mmm... good comments. I need to go and reread. 
I had assumed (but possibly incorrectly) that the sending of a
notification would still have to go through the RFC3413 MIB modules
and mechanisms. But you seem to read it as if these are hard-coded 
notification destinations. I need to check further and re-evaluate
if your interpretation is indeed correct.

> determines the sending of the notification "according to RFC 
> 3413". Well, I don't know how to interpret that instruction.
As I said, I need to check this one further. From your comment,
it seems that this mechanims might be better that using any address,
except that it needs to be more clear in how exactly it is intended
to select entries in the MIB modules of RFC3413.

> I've seen in other vendor MIB modules a similar attempt to 
> simplify the tables defined in RFC 3413 to manage the sending 
> of notifications. The above doesn't work, and it didn't 
> appear to me that the vendor approaches worked without other 
> simplifying assumptions.
> 
> for managing the delivery of notifications, and I believe 
> that there are many other problems in the MIB module (which I 
> came across, but have not described).
> 

David, Thanks again for pointing out how you were reading this.
It has alerted me to go and re-check with new energy and possible
new point of view.

Pls DO point out (if just in summary) any other SERIOUS issues
that you see in the MIB module.

> Hopefully, this flawed model is not being replicated in other 
> MIB modules, but probably is since I doubt the authors 
> invented this approach!
> 

Dan and I are following 802.1 MUB work in some detail. So we do
review (to the best of our ability) their MIB modules. But as always,
a fresh look on a MIB module often uncovers new/other issues.
That is exactly why we DO bring up some of this to the MIB doctors
list.

Bert
All the best in 2007!

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 29 Dec 2006 10:28:26 -0800 (PST)

HI,

Bert - maybe I misinterpreted your request for review.
I thought you wanted a look at the notification management
that was done in the MIB module. That's what I focused on,
and tried to stay focused on that issue. In reading the
MIB module, there were many other issues, and I didn't
report them because I thought you wanted a fast response
to the question you asked about - which was the notification
management. The approach that I took was to first decsribe
my interpretation of the behavior, to make sure that there
is a common understanding. (If a common understanding
can not be easily achieved, then no critical review
can be done.) Then to decribe the problems with this
approach.

If you would like a review of the MIB module, there
is additional info that I need, because the MIB module
by itself does not provide the background. (This is
not a problem because MIB modules are not suppose
to be tutorials on the technology they describe.)
Dan provided a URL to the IEEE document, and I can't
read it because I don't remember the user/password.
Would you send me a private email with that info,
since Dan has not responded to my request.

As to TDomain/TAddress vs TransportDomain/TransportAddress,
I don't see a difference in this case because RFC 3419
is really a clean up of TDomain/TAddress from RFC 2579
and basically says the two are interchangable! Section 3.1.2
tries to describes when each type of TC should be used,
and depending on how you slant your head when
reading that section, you will problably come up
with different advise. And my interpretation is
that in this MIB module, either one "will work",
but TransportDomain/TransportAddress are "more
general" and, thus my choice. (Bottom line for
me is that the choice is not a big concern
since BOTH sets of TCs will work to specify
an endpoint address.)

Regards,
/david t. perkins

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 29 Dec 2006 20:28:25 +0100

Thanks again for your further feedback/comments.

responses inline 

> Sent: vrijdag 29 december 2006 19:28
> To: Wijnen, Bert (Bert)
> Doctors \\\(E-mail\\\)
> that was done in the MIB module.

Well, my major request was to try and get consensus (which Dan and I
more or less concluded already) on the use of Tdoman/Address vs
TransportDomain/Address. I guess I focused fartoo much on that
myself instead of looking at the complete mechanism of sending
alarms at all. I guess that was caused because initially the 
SYNTAX for those objects was really bad.

> That's what I focused on, 
> and tried to stay focused on that issue. In reading the MIB 
> module, there were many other issues, and I didn't report 
> them because I thought you wanted a fast response to the 
> question you asked about - which was the notification 
> management. The approach that I took was to first decsribe my 
> interpretation of the behavior, to make sure that there is a 
> common understanding. (If a common understanding can not be 
> easily achieved, then no critical review can be done.) Then 
> to decribe the problems with this approach.
> 

Not sure I will get into re-reading/re-evaluating your interpretation.
But you may be quite right. And then I need to probably get the
authors to make more changes (which they will probably object to
very heavily).

> If you would like a review of the MIB module, there is 
> additional info that I need, because the MIB module by itself 
> does not provide the background. (This is not a problem 
> because MIB modules are not suppose to be tutorials on the 
> technology they describe.) Dan provided a URL to the IEEE 
> document, and I can't read it because I don't remember the 
> user/password.
> Would you send me a private email with that info, since Dan 
> has not responded to my request.
> 

I did that.
It would be good to have more review.
But it is also good to realize that Dan and I have been reviewing, 
and that the authors will be (very) reluctant to make more changes
unl;ess we find let us say "fatal flaws".

> As to TDomain/TAddress vs TransportDomain/TransportAddress, I 
> don't see a difference in this case because RFC 3419 is 
> really a clean up of TDomain/TAddress from RFC 2579 and 
> basically says the two are interchangable! Section 3.1.2 
> tries to describes when each type of TC should be used, and 
> depending on how you slant your head when reading that 
> section, you will problably come up with different advise. 
> And my interpretation is that in this MIB module, either one 
> "will work", but TransportDomain/TransportAddress are "more 
> general" and, thus my choice. (Bottom line for me is that the 
> choice is not a big concern since BOTH sets of TCs will work 
> to specify an endpoint address.)
> 

Mmm... so this is quire a different view from Juergen's view I think.

Bert
> >> Cc: David B Harrington; [email-masked]; MIB Doctors 
> >> \(E-mail\)
> >> There are many issues that I have with it, but putting them aside,
> >
> > aside. But... if you do put them aside... pls do not blame 
> any of us 
> > (who are involved in reviewing) for not having seen them.
> >
> >> The module contains a definition for a single 
> notification, which is 
> >> dot1agCfmFaultAlarm (which contains the single item 
> >> (each row in the table is one, and a "maintenance domain" 
> the network 
> >> or the part of the network for which faults in 
> connectivity are to be 
> >> The IEEE8021-CFM-MIB module includes definitions of two additional 
> >> OID values to be used as value for TransportDomain, which are:
> > This seems fine to me. It is very similar to zeroDotZero meaning no 
> > alarm is to be generated.
> > days) and I have not looked at it yet and what its 
> implications are. 
> > It might be strange, but I need to check it deeper before I can 
> > comment.
> >
> >> When an event occurs that matches the definition of the event of 
> >> notification dot1agCfmFaultAlarm, instead of using the 
> mechanisms as 
> >> defined in RFC 3413 to determine the filtering and delivery of a 
> >> notification, this module says that objects 
> >> are to be used.
> >> This is VERY problematic, since these objects do NOT have enough 
> >> info. Putting aside the case when 
> dot1agCfmMdFaultAlarmDestDomain has 
> >> the value dot1agTagList, the other cases are missing the following 
> >> info:
> > notification destinations. I need to check further and 
> re-evaluate if 
> > your interpretation is indeed correct.
> >
> >> transport address is actually a tag list, and that list determines 
> >> the sending of the notification "according to RFC 3413". Well, I 
> >> don't know how to interpret that instruction.
> > As I said, I need to check this one further. From your comment, it 
> > seems that this mechanims might be better that using any address, 
> > except that it needs to be more clear in how exactly it is 
> intended to 
> > select entries in the MIB modules of RFC3413.
> >
> simplify 
> >> the tables defined in RFC 3413 to manage the sending of 
> >> notifications. The above doesn't work, and it didn't appear to me 
> >> that the vendor approaches worked without other simplifying 
> >> assumptions.
> >>
> >> So, I believe that what was done in the IEEE module is BROKEN for 
> >> managing the delivery of notifications, and I believe that 
> there are 
> >> many other problems in the MIB module (which I came 
> across, but have 
> >> not described).
> >>
> >
> > It has alerted me to go and re-check with new energy and 
> possible new 
> > point of view.
> >
> > Pls DO point out (if just in summary) any other SERIOUS issues that 
> > you see in the MIB module.
> >
> >> Hopefully, this flawed model is not being replicated in other MIB 
> >> modules, but probably is since I doubt the authors invented this 
> >> approach!
> >>
> >
> > Dan and I are following 802.1 MUB work in some detail. So 
> we do review 
> > (to the best of our ability) their MIB modules. But as 
> always, a fresh 
> > look on a MIB module often uncovers new/other issues.

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 29 Dec 2006 12:33:07 -0800 (PST)

HI,

The following is found in IEEE802-1ag-d7-1:
  3.35 Owner: An owner of a system (and in particular, a Bridge) is
  defined in terms of the user-based security model of SNMPv3.
  An owner is a user (IETF RFC 3414) who has full
  access to the System Group
  of the SNMPv2-MIB (IETF RFC 3418).

I believe that "user" is inappropriate, and instead the
term "security principal" should be used, which is security
model independent.

I hope there are no other places that others are using security
model specific terms instead of security model independent terms,
especially now that there is more than one supported security
for the SNMPv3 protocol.

Regards,
/david t. perkins

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Dec 2006 21:48:32 +0100

> especially now that there is more than one supported security

And they assume that there is always one and exactly one "user" who
has full access to the System Group of the SNMPv2-MIB? How does this
go along with say appendix A.1 in RFC 3414? What happens if someone
configures security names and access control rules leading to multiple
owners?

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 29 Dec 2006 14:11:18 -0800 (PST)

HI,

Issues with the notification defined in MIB module IEEE8021-CFM-MIB:
1) There is only one notification, and it is reported
    when "A MEP has a persistent defect condition".
    Most other similar notifications have either another
    notification (or a variable in the OBJECTS clause)
    that indicates the reverse event (in this case,
    that the persistent defect condition has been
    resolved). As currently defined, when an notification
    receiver gets the notification, it must start
    polling the device to determine when the
    persistent defect is resolved instead of
    using another notification to indicate the
    resolution.
2) The persistent defect is not so simple. It is
    really the most important defect if multiple
    occur concurrently. However, the complex behavior
    is not described. For example, if first a
    not very important persistent defect occurs,
    and a notification is sent, but later a
    more important persistent defect occurs,
    is another notification sent?
3) The DESCRIPTION clause for the notification makes
    a reference to "Table 20-1". Well, there is no
    "Table 20-1" in the MIB module.
4) The DESCRIPTION clause says....
     "The management entity receiving the notification can identify
     the system from the network source address of the
     notification, and can identify the MEP reporting the defect
     by the indices in the OID of the dot1agCfmMepHighestPrDefect
     variable in the notification."
    Which is not correct in the proxy case, nor strictly speaking
    when SNMP is used over Ethernet (as specified in RFC 4789).
    Also, it would be quite useful to expand out and explain
    the indices for object dot1agCfmMepHighestPrDefect,
    such as:
      dot1agCfmMepHighestPrDefect - specifies the highest
        priority defect that has been present with it's
        indices identifying the MEP, which consist of:
          dot1agCfmMdIndex - index from the Maintenance Domain
                               table (dot1agCfmMdTable)
          dot1agCfmMaIndex - index from the Maintenance
                               Association table (dot1agCfmMaTable)
          dot1agCfmMepIdentifier - final index in the
                               Maintenance Association
                               End Point (MEP) table
                               (dot1agCfmMepTable) 
-------------------------
Continuing with other issues....

For me, the most important part of MIB module design is
describing the tables, including:
  1) consistent descriptions for how many entries are in
     each table and how that count is related to attributes
     of the system
  2) what are the relationships (if any) between the tables,
     and whether or not there is referential integrety between
     related tables. (For example, if in this MIB module,
     what happens to related entries in tables dot1agCfmMaTable
     and dot1agCfmMepTable when a related row in table
     dot1agCfmMdTable is deleted.)
  3) How are rows created and deleted in tables? Is this
     through operation of the system, and/or through
     management operations including SNMP. And if through
     SNMP operations, what must be done.
For this MIB module, some of the info is present, but it
is a little muddled. Some of the bigger issues are:

1) This module allows row creation for tables
dot1agCfmMdTable and  dot1agCfmMaTable
and uses the MIB design pattern of having an object
that indicates an unused index. This pattern works
only in limited cases, and for this MIB module,
it is appropriately applied for table dot1agCfmMdTable,
but not for table dot1agCfmMaTable. To support this
design pattern, object dot1agCfmMaTableNextIndex should
be a column of table dot1agCfmMdTable instead of
a scalar.

2) I don't understand the use of table dot1agCfmMaMepListTable,
it seems redundant with table dot1agCfmMepTable.

3) I don't see how entries in dot1agCfmStackTable come
into and go out of existance? What is the relationship
to rows in tables dot1agCfmMdTable and dot1agCfmMaTable?

4) Table dot1agCfmVlanTable seems to be underspecified.

5) Table dot1agCfmMepTable seems overly complex. It seems
    like it should be split up (but maybe this was already
    done). It's just quite messy as is.

---------------------
Other items that I would fix include:
1) fixing spelling
2) adding more text to the DESCRIPTION clause of the
    module identity to include:
    a) what the items defined in the module would be used for
       (help the reader to determine there the module is applicable)
    b) common abbreviations and acronyms
3) remove references in DESCRIPTION clauses to tables and other
    information in the IEEE 802.1ag document.

---------------
Good luck with further review and clean up. I spent a couple
of hours yesterday and about 2 hours today. I skimmed through
the IEEE document (it's approx 250 pages), and some of the
concepts that are not
explained in the MIB module are described in the IEEE document.
However, it is a long document, and is complicated by
it trying to add additional levels of adstraction to
VLANs. The security issues seem to me to be nonimplementable
by existing SNMP toolkits, but that question should be
better answered by the SNMP toolkit suppliers. Skimming
the document does confirm my concerns about notification
delivery - which is the MIB module simply specifies an
address to send a notification, which is not sufficient
for sending a notification.

Best wishes for the new year!

Regards,
/david t. perkins

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Dec 2006 17:04:53 -0800

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