Subject: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11

From: Hui Deng <[email-masked]>
Date: Sun, 25 Oct 2015 15:55:26 +0800

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

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 26 Oct 2015 01:29:23 +0000

Thanks for your review Deng Hui. Authors, can you please respond to this 
review and address the issues along with the ones raised in Carlos' Int Dir 
review.

Regards
Suresh

On 10/25/2015 03:55 AM, Hui Deng wrote:
> would treat comments from any other IETF contributors and resolve them along
> with any other
>
> 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.”
> 2)In the MIB definitions, it needs REFERENCE for the IMPORT objects. eg:
> 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,
> 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
> 5)In page 7, “Represents the tunnel type that the AFBR supports” in
> 6)As it states in the section 6.1, the ifInucastPkts counts the number of
> 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

---

From: Dong Jiang <[email-masked]>
Date: Mon, 26 Oct 2015 09:20:26 +0200

Dear Deng Hui,

Thank you for the comments! We'll revise the draft accordingly.

Best regards,
Jiang

2015-10-25 9:55 GMT+02:00 Hui Deng <[email-masked]>:

> 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
>
> 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
>
> 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
>