Skip to main content

Telechat Review of draft-ietf-softwire-mesh-mib-11
review-ietf-softwire-mesh-mib-11-intdir-telechat-hui-2015-11-20-00

Request Review of draft-ietf-softwire-mesh-mib
Requested revision No specific revision (document currently at 14)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2015-12-01
Requested 2015-11-20
Authors Yong Cui , Jiang Dong , Peng Wu , Mingwei Xu , Antti Yla-Jaaski
I-D last updated 2015-11-20
Completed reviews Genart Last Call review of -11 by Meral Shirazipour (diff)
Genart Telechat review of -12 by Meral Shirazipour (diff)
Intdir Telechat review of -11 by DENG Hui (diff)
Intdir Telechat review of -11 by Carlos Pignataro (diff)
Opsdir Last Call review of -11 by Scott O. Bradner (diff)
Assignment Reviewer DENG Hui
State Completed
Request Telechat review on draft-ietf-softwire-mesh-mib by Internet Area Directorate Assigned
Reviewed revision 11 (document currently at 14)
Completed 2015-11-20
review-ietf-softwire-mesh-mib-11-intdir-telechat-hui-2015-11-20-00
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