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 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:mamille2 at cisco.com] > Sent: Friday, November 13, 2015 6:42 AM > To: draft-ietf-softwire-dslite-mib.all at ietf.org; gen-art at ietf.org > 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 > Cisco Systems, Inc. > > > Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail