Telechat Review of draft-ietf-manet-smf-mib-10
review-ietf-manet-smf-mib-10-opsdir-telechat-schoenwaelder-2014-03-20-00

Hi,

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
operational area directors.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document defines a MIB module for an experimental multicast
forwarding protocol called SMF (Simplified Multicast Forwarding) for
MANETs. Since the MIB modules is specific for use in MANETs, I do not
expect any operational impact on the larger Internet. The intended
document status is experimental and the MIB module is proposed to be
registered under the experimental tree.

I believe the document is 'ready with issues'. It will be up to Benoit
to decide how to deal with them, given that this is an experimental
document and not a standards-track publication. Personally, I would
love to see at least the IANA module name(s) to change (see below).

Looking at the MIB module (which compiles fine), a few questions
popped up that I like to raise:

Why do you introduce two IANA modules? Would it not be simpler to use
a single IANA module for both textual conventions? The current naming
scheme for IANA modules is IANA-<SOMETHING>-MIB (the mixed case
notation has only been used in the early days. So in short, why do you
not but both textual convention definitions into say IANA-SMF-MIB?

I do not understand smfCfgInterfaceTable, which is supposed to augment
ifTable. Why do you need smfCfgIfName given that there is already
ifName in the ifXTable? How does cmfCfgIfAdminStatus interact with
ifAdminStatus? How does smfCfgIfRowStatus work on an augmenting table?
It escapes me how you create an interface in the base tables with this
mechanism. Looking at oage 60, it seems the RowStatus is limiting
itself to create the objects in the sparse augmentation. Perhaps this
can be made clearer in the DESCRIPTION clauses. Note that there is an
incomplete sentence in page 60. I also wonder why you use "-c public
-v 2c router" in the snmpwalk example while in the others you use
"[options]". (And of course I had to 'guess' what specific tool you
had in mind to make sense out of the examples. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <

http://www.jacobs-university.de/

>