Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process
draft-ietf-manet-smf-mib-13

- I would like to draw your attention to this IESG statement: Writable MIB Module IESG Statement,  https://www.ietf.org/iesg/statement/writable-mib-module.html
I guess that a discussion regarding configuration will be required at some point in time with the MANET WG. Up to the responsible AD to initiate this.
If you plan on specifying more MIB modules for configuration, then it would be good to include the RFC6982 experiment in your future drafts, specifically for the configuration aspects.
On the other hand, this document intended status is experimental, so I guess all is fine.

Interestingly, that relates to a comment I made in the past. https://datatracker.ietf.org/doc/rfc6779/ballot/#benoit-claise. I believe this is work is currently happening with draft-clausen-manet-olsrv2-management-snapshot


- The OPS-DIR review by Jürgen. Version 11 takes already into account some feedback. Thanks.
Two more issues currently in discussion: smfCfgIfName and the interaction of 'cmfCfgIfAdminStatus' with 'ifAdminStatus'
Adrian holds a DISCUSS on these. Fine.


- MIB doctor review by Dan Romascanu. The authors have fixed many issues. Thanks.
One issue left to discuss/document.

Running smilint results in the following level 5 warnings:  

mibs/SMF-MIB:396: [5] {inetaddresstype-subtyped} warning: `InetAddressType' should not be subtyped

mibs/SMF-MIB:421: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object

mibs/SMF-MIB:785: [5] {inetaddresstype-subtyped} warning: `InetAddressType' should not be subtyped

mibs/SMF-MIB:806: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object

mibs/SMF-MIB:824: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object

mibs/SMF-MIB:1112: [5] {inetaddresstype-subtyped} warning: `InetAddressType' should not be subtyped

mibs/SMF-MIB:1126: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object

mibs/SMF-MIB:1140: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object

mibs/SMF-MIB:1215: [5] {inetaddresstype-subtyped} warning: `InetAddressType' should not be subtyped

mibs/SMF-MIB:1226: [5] {inetaddress-inetaddresstype} warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object

Concerning the first category of warnings ' InetAddressType' should not be subtyped ': indeed, as per RFC 4001: 
 
         To support future extensions, the InetAddressType textual
         convention SHOULD NOT be sub-typed in object type definitions.
         It MAY be sub-typed in compliance statements in order to
         require only a subset of these address types for a compliant
         implementation.
 

Dan recommended giving up subtyping in the MIB and moving it to the compliance statements for the respective objects. You went to a solution consistent with what was done in the other MANET MIB documents, but contrary to the recommendation.

DISCUSS or COMMENT? The recommendation has a clear SHOULD NOT and the argument that it was done twice wrong does not justify making it wrong the third time. On the other hand smilint flags this as a warning only (level 5 error) and  there are no complaints from previous implementations which can mean that either the first two MIB modules are not implemented or there are no problems indeed. So, at the end of the day, and in agreement with Dan, it's more a COMMENT than a DISCUSS. Up to responsible AD to decide.
If the responsible AD doesn't feel like imposing the change, here is a proposal: A sentence or two in the draft justifying why this RFC violates the recommendations. 
I could live with that considering that the issue is documented, and that this RFC is experimental.




EDITORIAL:
- No need to have [SMF] below
  DESCRIPTION
         "This MIB module contains managed object definitions for
          the Manet SMF RSSA process defined in:

          [SMF] Macker, J.(ed.),
          Simplified Multicast Forwarding, RFC 6621,
          May 2012.

          Copyright (C) The IETF Trust (2012). This version
          of this MIB module is part of RFC xxxx; see the RFC
          itself for full legal notices."

Thanks for addressing my concerns.

A quick scan of this document does not indicate any apps worries, so I will leave it to my colleagues to comment more extensively.

The uses of requirements language in section 8 is weird to me. The fact that I mention it will probably require that I buy Benoit a beer to discuss it. But I don't imagine it's worth discussing in the context of this particular document.

My review on this document was more to look for anything I ought to look more closely at, and I found nothing objectionable (Brian's the multicast expert), so I am No Objecting on that basis.