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

[Ballot comment]
I'm changing my ballot to Yes with the new revision. I trust Juergen to speak up if he is not happy with the changes made to address his OpsDir review.

[Ballot comment]
- 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."

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
1. I would like to know the history of smfCfgAddrForwardingTable.  It would be good if the document contained some discussion of the differences between smfCfgAddrForwardingTable and RFC 5132.

2. It appears that the smfPerformanceGroup replicates some of the counters defined in RFC 4293.  Is there an expectation that SMF devices will not implement the standard IP MIB?

[Ballot comment]
1. The copyright date in the MIB description is incorrect (or there has been a time warp).

2. I notice that the smfConfigurationGroup has read-write objects.  Is there really an expectation that operators will use SNMP to configure SMF-capable devices within a mobile ad hoc network?

3. The DESCRIPTION clause for smfCfgAddrForwardingTable contains the phrase "multicast multicast addresses".

Changes are expected over time. This version is dated December 1, 2012.
(1.a) Stan Ratliff (sratliff@cisco.com) is the document shepherd for this document.
        The shepherd has personally reviewed the document, and believes it is ready
        for forwarding to the IESG for publication.
(1.b) The document has had adequate review from both key working group members
        and from key non-WG members. The shepherd does not have any concerns
        about the depth or breadth of the reviews that have been performed.
(1.c) The shepherd does not have any concerns about the document needing
        additional review.
(1.d) The shepherd does not have any concerns or issues with the document that the
          responsible Area Director or the IESG need to be aware of. IPR disclosures
          were not necessary, therefore, none have been filed.
(1.e) Working group consensus behind this document is solid. The document
          represents strong concurrence of the working group as a whole, the the WG
          understands and agrees with the document.
(1.f) No one has threatened appeal or has indicated discontent with the document.
(1.g) The document shepherd has run the "idnits" tool against the document. The
          document has met all required formal review criteria.
(1.h) The document has split its references into normative and informative. There are
          no downward references.
(1.i) The shepherd has verified that document IANA consideration section exists, and
        is consistent with the body of the document. No protocol extensions are
        requested. The necessary IANA registries are clearly defined. No new registries
        are requested. No expert review has been requested.
(1.j) The document has been run through the "smilint" checker. No warnings (at any
        level) or errors exist.
(1.k) The IESG approval announcement includes a Document Announcement Write-
        Up. Please provide such a Document Announcement Write-Up? Recent
        examples can be found in the "Action" announcements for approved documents.
        The approval announcement contains the following sections:
  Technical Summary
        This document defines a portion of the Management Information Base (MIB) for
        use with the Simplified Multicast Framework (SMF) RFC6621 developed in the
        MANET working group.
  Working Group Summary
        The process for reaching working group consensus on this was smooth; no
        controversy existed. Working group consensus behind the document is solid.
  Document Quality
        This document shepherd is not aware of existing implementations of this MIB
        although a joint development is underway between the US Naval Research
        laboratory and the US Army CERDEC organizations.
        Early review by MIB doctor was discussed within the working group, however,
        the WG consensus was that this review was unnecessary, as the WG contains
        sufficient expertise to determine applicability of all objects, and correctness of
        the MIB.
        MIB doctor review during IETF last call resulted in considerable discussion and
        document revision. The version entering IESG evaluation is believed to address
        all issues needing change although there was one issue where the authors
        believe the MIB Doctor is advocating a different approach rather than stating
        something that needs to be changed.

email sent
=====

Hi,

Thanks to Bob for spinning a new revision.

I think the process here is...

1. Dan to have a look as MIB Doctor with whatever cycles he as ( >= 0)
2. Chairs to run this past the WG to see whether anyone objects to the changes made
3. Back to me to advance the document.

I will wait to hear from the chairs.

Thanks,
Adrian

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-manet-smf-mib-08.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has a question about the IANA action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there is
a single action which IANA must complete.

The authors request that:

"The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry:

Descriptor OBJECT IDENTIFIER value
---------- -----------------------
SMF-MIB { experimental XXXX }
IANA EDITOR NOTE: please assign XXXX, and remove this note."

IANA Question --> By marking the Object Identifier experimental, do the authors intend that the MIB definition result in the following addition being made to the SMI Experimental Codes registry (iso.org.dod.internet.experimental (1.3.6.1.3)) located at:

http://www.iana.org/assignments/smi-numbers/

in the following way:

a new code will be registered as follows:

Decimal: [ TBD by IANA at time of registration ]
Name: SMF-MIB
Description: Simplified Multicast Framework
References: [ RFC-to-be ]

---
IANA understands this to be the only action required of IANA upon
approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Definition of Managed Objects for the Manet Simplified Multicast
  Framework Relay Set Process'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-10-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet community.
  In particular, it describes objects for configuring aspects of the
  Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc
  Networks (MANETs).  The SMF-MIB also reports state information,
  performance metrics, and notifications.  In addition to
  configuration, the additional state and performance information is
  useful to operators troubleshooting multicast forwarding problems.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ballot/

No IPR declarations have been submitted directly on this I-D.

AD review
=====

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.

Changes are expected over time. This version is dated December 1, 2012.
(1.a) Stan Ratliff (sratliff@cisco.com) is the document shepherd for this document. The shepherd has personally reviewed the document, and believes it is ready for forwarding to the IESG for publication.
(1.b) The document has had adequate review from both key working group members and from key non-WG members. The shepherd does not have any concerns about the depth or breadth of the reviews that have been performed.
(1.c) The shepherd does not have any concerns about the document needing additional review.
(1.d) The shepherd does not have any concerns or issues with the document that the responsible Area Director or the IESG need to be aware of. IPR disclosures were not necessary, therefore, none have been filed.
(1.e) Working group consensus behind this document is solid. The document represents strong concurrence of the working group as a whole, the the WG understands and agrees with the document.
(1.f) No one has threatened appeal or has indicated discontent with the document.
(1.g) The document shepherd has run the "idnits" tool against the document. The document has met all required formal review criteria.
(1.h) The document has split its references into normative and informative. There are no downward references.
(1.i) The shepherd has verified that document IANA consideration section exists, and is consistent with the body of the document. No protocol extensions are requested. The necessary IANA registries are clearly defined. No new registries are requested. No expert review has been requested.
(1.j) The document has been run through the "smilint" checker. No warnings (at any level) or errors exist.
(1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
  Technical Summary This document defines a portion of the Management Information Base (MIB) for use with the Simplified Multicast Framework (SMF) RFC6621 developed in the MANET working group.
  Working Group Summary The process for reaching working group consensus on this was smooth; no controversy existed. Working group consensus behind the document is solid.
  Document Quality This document shepherd is not aware of existing implementations of this MIB; although a joint development is underway between the US Naval Research laboratory and the US Army CERDEC organizations. Review by MIB doctor was discussed within the working group, however, the WG consensus was that this review was unnecessary, as the WG contains sufficient expertise to determine applicability of all objects, and correctness of the MIB.

Changes are expected over time. This version is dated December 1, 2012.
(1.a) Stan Ratliff (sratliff@cisco.com) is the document shepherd for this document. The shepherd has personally reviewed the document, and believes it is ready for forwarding to the IESG for publication.
(1.b) The document has had adequate review from both key working group members and from key non-WG members. The shepherd does not have any concerns about the depth or breadth of the reviews that have been performed.
(1.c) The shepherd does not have any concerns about the document needing additional review.
(1.d) The shepherd does not have any concerns or issues with the document that the responsible Area Director or the IESG need to be aware of. IPR disclosures were not necessary, therefore, none have been filed.
(1.e) Working group consensus behind this document is solid. The document represents strong concurrence of the working group as a whole, the the WG understands and agrees with the document.
(1.f) No one has threatened appeal or has indicated discontent with the document.
(1.g) The document shepherd has run the "idnits" tool against the document. The document has met all required formal review criteria.
(1.h) The document has split its references into normative and informative. There are no downward references.
(1.i) The shepherd has verified that document IANA consideration section exists, and is consistent with the body of the document. No protocol extensions are requested. The necessary IANA registries are clearly defined. No new registries are requested. No expert review has been requested.
(1.j) The document has been run through the "smilint" checker. No warnings (at any level) or errors exist.
(1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
  Technical Summary This document defines a portion of the Management Information Base (MIB) for use with the Simplified Multicast Framework (SMF) RFC6621 developed in the MANET working group.
  Working Group Summary The process for reaching working group consensus on this was smooth; no controversy existed. Working group consensus behind the document is solid.
  Document Quality This document shepherd is not aware of existing implementations of this MIB; although a joint development is underway between the US Naval Research laboratory and the US Army CERDEC organizations. Review by MIB doctor was discussed within the working group, however, the WG consensus was that this review was unnecessary, as the WG contains sufficient expertise to determine applicability of all objects, and correctness of the MIB.