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:[email protected]] Sent: Friday, November 13, 2015 6:42 AM To: [email protected]; [email protected] 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 <[email protected]> Cisco Systems, Inc. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
