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

["Matt Miller (mamille2)" <[e-mail]>]

The changes look good to me, and address all of my nits.


Thanks Yu!

--
- m&m

Matt Miller
Cisco Systems, Inc.

> On Nov 26, 2015, at 02:13, Yu Fu <[e-mail]> wrote:
> 
> 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.
> 
> 
>