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

"Matt Miller (mamille2)" <mamille2@cisco.com> Thu, 12 November 2015 22:42 UTC

From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: "draft-ietf-softwire-dslite-mib.all@ietf.org" <draft-ietf-softwire-dslite-mib.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>
Thread-Topic: Gen-ART LC Review of draft-ietf-softwire-dslite-mib-11
Thread-Index: AQHRHZtjWI6rqNQ420y+H97gCzSU5Q==
Date: Thu, 12 Nov 2015 22:42:19 +0000
Message-ID: <5053E81C-A6AF-4398-949F-CBE045F537EA@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [64.101.72.28]
Content-Type: multipart/signed; boundary="Apple-Mail=_046A49B8-E119-45A5-8975-A44DC5438FD7"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/6QJOZmw9Ma9KMgO4eDdoxJf5enk>
Subject: [Gen-art] Gen-ART LC Review of draft-ietf-softwire-dslite-mib-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2015 22:42:23 -0000

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 <mamille2@cisco.com>
Cisco Systems, Inc.

Attachment: signature.asc

[Gen-art] Gen-ART LC Review of draft-ietf-softwir… Matt Miller (mamille2)
Re: [Gen-art] Gen-ART LC Review of draft-ietf-sof… Yu Fu
Re: [Gen-art] Gen-ART LC Review of draft-ietf-sof… Matt Miller (mamille2)

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

Attachment: signature.asc