Re: [Gen-art] Gen-ART LC Review of draft-ietf-softwire-dslite-mib-11

["Yu Fu" <[e-mail]>]

Hi Matt,

Thanks for your review. All the nits have been corrected in the updated
version.

Thanks again

BR
Yu

-----Original Message-----
From: Matt Miller (mamille2) [mailto:[e-mail]] 
Sent: Friday, November 13, 2015 6:42 AM
To: [e-mail]; [e-mail]
Subject: Gen-ART LC Review of draft-ietf-softwire-dslite-mib-11

I am the assigned Gen-ART reviewer for this draft. The General Area Review
Team (Gen-ART) reviews all IETF documents being processed by the IESG for
the IETF Chair.  Please treat these comments just like any other last call
comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-softwire-dslite-mib-11
Reviewer: Matthew Miller
Review Date: 2015-11-12
IETF LC End Date: 2015-11-15
IESG Telechat date: N/A

Summary:

This document is ready to be published as a Standards Track RFC, but with
nits that ought to be addressed before publication.

Major issues:

Minor issues:

Nits/editorial comments:

* Note that draft-perrault-behave-natv2-mib is now RFC 7659; the reference
should be updated when (if) this document is updated.

* In section 4. "Relationship to the IF-MIB", "(physical or virtual)has an
ifEntry"
is missing a space between "virtual)" and "has".

* In section 5. "Difference from the IP tunnel MIB and NATV2-MIB", the fifth
paragraph was difficult for me to understand at first.
Assuming I understood the idea being expressed, maybe the following is
better:

OLD:

   In the DS-Lite scenario, the Address Family Transition Router (AFTR)
   is not only the tunnel end concentrator, but also a 4-4 translator.
   So as defined in [RFC6333] , when the IPv4 packets come back from the
   Internet to AFTR, the AFTR knows how to reconstruct the IPv6
   encapsulation by doing a reverse lookup in the extended IPv4 NAT
   binding table.  So the NAT binding table in the AFTR MUST be extended
   to include the IPv6 address of the tunnel initiator.  But the tunnel
   information defined in NATV2-MIB is on the address level.  Because
   the TUNNEL-MIB defined the objects on the view of interface, the DS-
   Lite-MIB need define the tunnel objects to extend the NAT binding
   entry by interface for accordance.  Therefore, a combined MIB is
   necessary.

NEW:

   In the DS-Lite scenario, the Address Family Transition Router (AFTR)
   is not only the tunnel end concentrator but also a 4-4 translator.
   As defined in [RFC6333], when the IPv4 packets come back from the
   Internet to the AFTR, it knows how to reconstruct the IPv6
   encapsulation by doing a reverse lookup in the extended IPv4 NAT
   binding table.  The NAT binding table in the AFTR MUST be extended
   to include the IPv6 address of the tunnel initiator.  However, the
   tunnel information defined in NATV2-MIB is on the address level.
   Because the TUNNEL-MIB defined the objects on the view of interface
   rather than the address, the DS-Lite-MIB needs to define the tunnel
   objects to extend the NAT binding entry by interface.  Therefore, a
   combined MIB is necessary.

* In section 6. "Structure of the MIB Module", "a" should be added between
"in" and "DS-Lite" in the sentence "The DS-Lite MIB provides a way to
monitor and manage the devices (AFTRs) in DS-Lite scenario through SNMP."

* In section 6.1.1. "The dsliteTunnel Subtree", "DS- Lite" should be
"DS-Lite".

* In section 6.1.1., the phrasing of "some objects defined in the IP Tunnel
MIB are not read-write and read-only" is confusing to me.  I'm not sure this
means "are not read-write but are read-only" or "are not readable" (which
there's a definition in section 9); are one of these interpretations
correct?

* In Section 9. "Security Considerations", the phrase "even then" seems to
be superfluous, and can be removed.

* In section 10. "IANA Considerations", "IP Tunnel MIB[RFC4087]" should be
"IP Tunnel MIB [RFC4087]".


--
- m&m

Matt Miller <[e-mail]>
Cisco Systems, Inc.