Softwire Mesh Management Information Base (MIB)
draft-ietf-softwire-mesh-mib-14

[Ballot discuss]
From the diff, I spotted that you imported smi-2. It should be mib-2
So basically, you haven't checked that your MIB module compiles :-(
http://www.ibr.cs.tu-bs.de/bin/smitools.cgi
Your request has been processed by the command

timeout 10 smilint -s -e -l 6 mibs/SOFTWIRE-MESH-MIB 2>report.txt

You can access any intermediately created files, the processing report (which might be empty if no errors or warnings have been found), and output files (in case of a conversion request) for reading and download from a temporary server directory for approx. 24 hours.

While processing your request the following errors and/or warnings have been found:

mibs/SOFTWIRE-MESH-MIB:4: [2] {import-failed} identifier `smi-2' cannot be imported from module `SNMPv2-SMI'
mibs/SOFTWIRE-MESH-MIB:56: [2] {bad-identifier-case} `XXX' should start with a lower case letter
mibs/SOFTWIRE-MESH-MIB:56: [2] {object-identifier-not-prefix} Object identifier element `XXX' name only allowed as first element
mibs/SOFTWIRE-MESH-MIB:56: [1] {object-identifier-unknown} unknown object identifier label `mib-2'
mibs/SOFTWIRE-MESH-MIB:19: [2] {module-identity-registration} illegal module identity registration
mibs/SOFTWIRE-MESH-MIB:121: [5] {index-exceeds-too-large} warning: index of row `swmEncapsEntry' can exceed OID size limit by 136 subidentifier(s)
mibs/SOFTWIRE-MESH-MIB:221: [5] {index-exceeds-too-large} warning: index of row `swmBGPNeighborEntry' can exceed OID size limit by 135 subidentifier(s)

[Ballot comment]
- section 5.1, first two sentences:
The text can be interpreted to mean the subtree is the mechanism for that negotiation. I assume that's not the intent?

-5.1, last sentence:
I don't understand; what different tunnel?

-8, paragraph 6:
Do the 2119 keywords in this paragaph represent new requirements specified in this draft, or do they describe existing requirements from SNMPv3? If the latter, please use descriptive language rather than 2119 keywords.

-5.1, Third sentence:
Missing article before "Softwire mesh framework...".

[Ballot comment]
From Dave Thaler (MIB doctors)
It does contain an number of typos and English grammar issues that should be addressed before publication.
I put a marked up copy up where it should shortly appear as http://research.microsoft.com/~dthaler/draft-ietf-softwire-mesh-mib-12.pdf

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-softwire-mesh-mib-11.txt. If any part of this review is inaccurate, please let us know.

IANA has questions about the actions to be completed for this document:

In the SMI Network Management MGMT Codes Internet-standard MIBsubregistry of the Network Management Parameters registry located at:

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

a new MIB will be registered as follows:

Decimal: [ TBD by IANA at time of registration ]
Name: swmMIB
Description: Softwire Mesh
References: [ RFC-to-be ]

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

QUESTION TO AUTHORS: We want to be absolutely sure where this mib assignment goes. We understand this to be a mib-2 assignment as described in the Editor's note.  However, the assignment for mib is described as follows:

swmMIB            { transmission XXX }

Should this be a transmission assignment?
Also, we see softwireMesh ("xx").

Is this an additional assignment?

Can you clarify the exact request for assignment and which registry?

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: softwires@ietf.org, draft-ietf-softwire-mesh-mib@ietf.org, softwire-chairs@ietf.org, suresh.krishnan@ericsson.com, terry.manderson@icann.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Softwire Mesh Management Information Base (MIB)) to Proposed Standard


The IESG has received a request from the Softwires WG (softwire) to
consider the following document:
- 'Softwire Mesh Management Information Base (MIB)'
  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 2015-11-15. 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 defines objects for managing softwire mesh.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib/ballot/


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

Hui Deng performed an INT area review:

Hi

I am an assigned INT directorate reviewer for draft-ietf-softwire-mesh-mib-11. These comments were written primarily for the benefit of the Internet Area Directors.

Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other

Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate/intarea.html.

This document defines MIB objects to manage softwire mesh solutions, and targets the Standards Track.

Please find below review comments:

1) Page 5 in section 6.2, “The tunnelIfRemoteInetAddress MUST be set to 0.0.0.0 for IPv4 or :: for IPv6 because it is a point to multi-point tunnel.”
It needs quotation mark for 0.0.0.0 and ::

2) In the MIB definitions, it needs REFERENCE for the IMPORT objects. eg:
swmEncapsEIPDst OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The E-IP destination prefix, which is
used for I-IP encapsulation destination looking up."
::= { swmEncapsEntry 2 }

It should add a REFERENCE “E-IP and I-IP in RFC 5565 ”. The same comment for the definition of swmEncapsIIPDst.

3) In page 8,
swmEncapsEIPDstType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object specifies the address type used for
swmEncapsEIPDst. It is different from the tunnelIfAddressType
in the tunnelIfTable."
::= { swmEncapsEntry 1 }

It should list ipv4(1) and ipv6(2) in the DESCRIPTION for different scenario. Also it should add a REFERENCE to RFC 4001.

4) In page 8, SwmEncapsEntry: I think swmEncapsEIPDstType and swmEncapsIIPDstType should just be swmEncapsIPDstType and apply to both. If all address objects in

the row are of the same type, you only need one type object.

5) In page 7, “Represents the tunnel type that the AFBR supports” in definition of swmSupportedTunnelType. It need a clarification that It represents the tunnel

type used for softwire mesh scenario.

6) As it states in the section 6.1, the ifInucastPkts counts the number of IPv6 packets which are sent to the virtual interface for decapsulation into IPv4. I

think it need some statistics objects to define for the softwire mesh such as the number of the connection tunnel when running point to multi-point tunnel.

7) Why not define a parameter for swmEncapsIIPDstPrefixLength?

8) In the swmEncapsGroup, there are only information about swmEncapsIIPDst and swmEncapsIIPDstType, why there are not swmEncapsEIPDst and swmEncapsIIPType and so on?

Best regards,

DENG Hui

Carlos Pignataro performed an INT Area review


Hi,

I am an assigned INT directorate reviewer for draft-ietf-softwire-mesh-mib-11. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate/intarea.html.

This document defines MIB objects to manage softwire mesh solutions, and targets the Standards Track.

I have a number of comments and concerns with this document, which amount to requesting the ADs to take a closer look:

3.  Terminology

  This document uses terminology from the softwire problem statement
  RFC 4925 [RFC4925] and the softwire mesh framework RFC 5565
  [RFC5565].

CMP: I think terminology from RFC 5512 is also heavily used.

5.1.  The swmSupportedTunnelTable Subtree

  According
  to section 4 of RFC 5512 [RFC5512], current softwire mesh tunnel
  types include IP-IP, GRE and L2TPv3.

CMP: This is true, but at the same time there are now many other “current tunnel types” (which are actually BGP Tunnel Encapsulation Attribute Tunnel Types). See http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types Specifically the ones introduced by RFC5566 ought to be included.

CMP: This comment also applies to swmSupportedTunnelType

XX. Missing sub-TLVs

CMP: If the Tunnel Type is one which requires encapsulation information (e.g., L2TPv3 Session ID, Cookie, GRE Key, etc.), how is that information managed? I cannot seem to find it in the MIB Module. See Section 4.1 of RFC 5512.

CMP: Similarly, what about Protocol Type and Color (S4.2 and 4.3 of RFC 5512), and IPsec Tunnel Authenticator (RFC 5566)?

CMP: Similarly, what about the Load-Balancing Block values from RFC 5640? Without this, an ECMP-aware L2TPv3 tunnel will be misunderstood.

8.  Security Considerations

  The swmMIB module can be used for configuration of certain objects,

CMP: How is this so, without read-write or read-create?

11.  References

11.1.  Normative References

CMP: Curiously, I do not see RFC 5566 or RFC 5640 referenced.

Hope these help!

Thanks,

— Carlos.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.

(2) 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

  The Softwire mesh framework is a tunneling mechanism that enables
  the connectivity between islands of IPv4 networks across a single
  IPv6 backbone and vice versa.  In softwire mesh, extended
  multiprotocol-BGP (MP-BGP)is used to set up tunnels and advertise
  prefixes among address family border routers (AFBRs).  The softwire
  mesh MIB provides a method to configure and manage the softwire
  mesh objects through SNMP.

Working Group Summary

  The working group had active discussion on the draft and the current
  text of the draft is representative of the consensus of the working
  group. There were no controversial discussions regarding this
  document.

Document Quality

  The document has received adequate review. The Document Shepherd has
  no concerns about the depth or breadth of these reviews. There was a
  MIB doctor review that raised a few issues that have since been
  resolved.

Personnel

  Suresh Krishnan is the document shepherd. Terry Manderson is the
  responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed several versions of this document. Earlier versions of
the document had some clear issues that needed to be fixed. So I
requested an early MIB doctor review. The issues have since been
resolved.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document needed specialized review from the MIB perspective and
the MIB doctor review by Dave Thaler provided that.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The MIB contained in the document produces two warnings with smilint
as described in Question 19. The MIB doctor review of this document in
version -03 did not contain any remarks about these warnings and I am
assuming this warning are benign. I just wanted to provide a heads
up to the OPS ADs.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The consensus behind this document is pretty weak as this document was
held back until the softwire stateless transition solutions went
through the publication process. The document represents strong
concurrence of a few individuals with nobody opposed.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document has been reviewed by MIB doctors.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document requires two IANA actions. It requires an assignment
under the SMI Numbers registry and it registers a new tunnel type.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

I ran the libsmi checker on the document. It threw up two errors and
two warnings.

The two errors that come up are

mibs/SOFTWIRE-MESH-MIB:56: [2] {object-identifier-not-prefix} Object
identifier element `xxx' name only allowed as first element

mibs/SOFTWIRE-MESH-MIB:18: [2] {module-identity-registration} illegal
module identity registration

These will get fixed once IANA allocates the value xxx. I did put in
an available number to check and these errors went away.

The two warnings were also produced. Not sure what is causing these. A
look at the swmEncapsEntry and swmBGPNeighborEntry does not show any
obvious issues.

mibs/SOFTWIRE-MESH-MIB:110: [5] {index-exceeds-too-large} warning:
index of row `swmEncapsEntry' can exceed OID size limit by 136
subidentifier(s)

mibs/SOFTWIRE-MESH-MIB:198: [5] {index-exceeds-too-large} warning:
index of row `swmBGPNeighborEntry' can exceed OID size limit by 135
subidentifier(s)