Please see attached review.
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pim-group-rp-mapping-07.txt Reviewer: Brian Carpenter Review Date: 2010-12-18 IETF LC End Date: 2010-12-23 IESG Telechat date: Summary: In good shape, a few issues. -------- Major issues: ------------- 3. Existing algorithm ... The algorithm defined in this document updates algorithm defined in PIM-SM ( Section 4.7.1 in [RFC4601]). The new algorithm is backward compatible and will produce the same result only if the Group-to-RP mappings are learned from a single mapping source. A logical implication of the last sentence is that if some of the Group-to-RP mappings are learned from more than one mapping source, the new algorithm might not produce the same result as the existing algorithm. Is that indeed the case, and if so, don't we have a problem until all PIM-SM routers have been updated? 5. Common use cases o Default static Group-to-RP mappings with dynamically learned entries Many network operators will have a dedicated infrastructure for the standard multicast group range (224/4) and so might be using statically configured Group-to-RP mappings for this range. Please indicate whether this issue also applies to IPv6. 6. Proposed algorithm ... 10. From the remaining set of Group-to-RP Mappings we will select the RP with the highest IP address. This will serve as a final tiebreaker. Please define "highest". Does it mean "greatest when considered as an unsigned integer"? 8. Clarification for MIB Objects When a Group-to-RP mapping entry is created in the pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be acceptable to have an entry with an RP with address type 'unknown' and a PimMode of Dense Mode or SSM. These entries would represent group ranges for Dense mode or SSM. Also all the entries which are already included in the SSM Range table in the IP Mcast MIB would be copied over to pimGroupMappingTable. They would have a type of configSSM and an RP with address type 'unknown' as described above. Is this section intended to be a normative update of RFC 5060, or is it just commentary? The phrase "it would be acceptable" almost sounds like a normative MAY. Also, shouldn't it be 'unknown(0)' in the context of the MIB? (This applies in three places in the draft.) Nits: ----- 5. Common use cases ... o More use cases By no means, the above list is complete. Please drop a mail to 'authors' if you see any other use case for this. This seems a bit strange to appear in the final RFC; at the least it needs rewriting. The checker says: == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
