[manet] AD review of draft-ietf-manet-smf-mib

["Adrian Farrel" <[e-mail]>]

Hi,

Thanks for this document. Here is my AD review, the purpose of which is
to iron out issues before the document goes to IETF last call and IESG
review.

I don't have any major issues with your document, but here is a list of
minor points for consideration. All issues are up for discussion, but I
think  new revision is needed.

Thanks,
Adrian

---

In a couple of places you say "MIBs" when you should say "MIB modules"
For example:
   6.3  Relationship to the Future RSSA-MIBs

This is hardly important, but could do with being cleaned up.

---

Please don't use direct citations (in square brackets) within the body
of the MIB module. This is because the text of the MIB module will be
extracted and used as a standalone file. You already have Section 6.2
to ensure that all the references are made correctly, so all you need
to do is remove the square brackets, from within Section 7, leaving the
contents in place.
E.g.
OLD
         FROM SNMPv2-SMI                          -- [RFC2578]
NEW
         FROM SNMPv2-SMI                          -- RFC 2578
END

E.g.
OLD
          [SMF] Macker, J.(ed.),
          Simplified Multicast Forwarding, RFC XXXX,
          July 2012.
NEW
          RFC XXXX, Macker, J.(ed.),
          Simplified Multicast Forwarding, July 2012.
END

---

Copyright in the MIB module itself is out of date.

---

Please resolve the different 'XXXX' and 'xxxx' so that they are unique.
Thus,
        DESCRIPTION
           "The first version of this MIB module,
            published as RFC xxxx.
           "
        -- RFC-Editor assigns xxxx
        ::= { experimental xxxx }   -- to be assigned by IANA
...contains two different meanings of xxxx.

---

SmfOpModeID has
       SYNTAX  INTEGER {
                        independent (1),
                        routing (2),
                        crossLayer (3)
                        -- future (4-255)
               }

I take from this that:
1. the range of SmfOpModeID is 1-255
2. You do not want to assign 4-255 at this time

I think that means that you should have either
       SYNTAX  INTEGER (1..255)
and put the interpretation in comments (which isn't so helpful); or
       SYNTAX  INTEGER {
                        independent (1),
                        routing (2),
                        crossLayer (3)
               }

How worried are you that new values will be defined, and what will you
do when they are? If this is going to happen relatively soon, then you
would need to respin the whole RFC and MIB module to add the value. That
is a pain!

In that case, you would be better to move the TC to a separate MIB
module so that it can be updated without revising the OID of the main
module.

It may be that the operational mode needs to follow the setting of a
specific protocol field. In that case, you may prefer to put this TC in
an IANA MIB module so that it can be updated automatically.

See also comment on SmfRssaID.

---

There is a similar problem with enumerations and ranges in SmfRssaID.
Here you have:
       SYNTAX      INTEGER {
                           cF(1),
                           sMPR(2),
                           eCDS(3),
                           mprCDS(4)
                           -- future(5-127)
                           -- noStdAction(128-239)
                           -- experimental(240-255)
                   }

Again, I think you should either have
       SYNTAX      INTEGER (1..255)
with the information in the comment; or
       SYNTAX      INTEGER {
                           cF(1),
                           sMPR(2),
                           eCDS(3),
                           mprCDS(4),
                           exp0(240),
                           exp1(241),
                           exp2(242),
                           exp3(243),
                           exp4(244),
                           exp5(245),
                           exp6(246),
                           exp7(247),
                           exp8(248),
                           exp9(249),
                           exp10(250),
                           exp11(251),
                           exp12(252),
                           exp13(253),
                           exp14(254),
                           exp15(255)
                   }
and move the TC into a separate MIB module (possibly operated by IANA)
so that it can be easily updated.

---

   smfOpModeCapabilitiesReference OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object contains a reference to the document
            that defines this operational mode."
       ::= { smfOpModeCapabilitiesEntry 3 }

I think you probably need a proper reference for the format of the
string here. Is the document referenced through a URI or what?

---

You have DEFVAL clauses for a number of objects that have MAX-ACCESS
of read-write.  I don't think this makes sense.  Defaults only apply to
creatable objects meaning "this is the value to apply if this object is
created automatically without being explicitly set."

Otherwise it is entirely up to the local implementation how it sets the
object. While there may be an approved default value for a protocol
implementation, that is not a DEFVAL, but a piece of information in a
protocol specification.

---

   smfIfIndex  OBJECT-TYPE
      SYNTAX      InterfaceIndexOrZero

If you use InterfaceIndexOrZero rather than InterfaceIndex, you must
state the meaning of zero for the object.

---

Are you sure you need smfIfName in addition to ifDescr?
Are you sure you need smfIfAdminStatus in addition to ifAdminStatus?

---

A number of references of the form...

       REFERENCE
          "Simplified Multicast Forwarding for MANET
           (SMF), Macker, J., July 2012."

...should really include the RFC number (i.e. 6621) to read...

       REFERENCE
          "RFC 6621, Simplified Multicast Forwarding for MANET
           (SMF), Macker, J., July 2012."

For example at SmfOpModeID, but search for them all.

---

I think that the SMF Performance Group needs some discussion of wrapping
and discontinuities.  I think wrapping is as simple as making a 
statement that the counters wrap to zero.  I don't really understand how
to describe discontinuities - you need a MIB expert for that.