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 . Document: draft-ietf-pim-drlb-13 Reviewer: Pete Resnick Review Date: 2019-11-05 IETF LC End Date: 2019-11-07 IESG Telechat date: Not scheduled for a telechat Summary: Ready with some minor issues and nits, plus one "interesting note". Major issues: None. Minor issues: In 5.1, the SHOULDs regarding the default hash masks seem a bit odd: Usually SHOULD means that bad things are likely to happen if you choose otherwise, but if you know what you are doing, you might choose something different. Is there any real harm to choosing some other hash masks, or are you simply saying that these are perfectly reasonable? Not a big deal one way or the other, but if there is harm, you should probably say something about that. In 5.1: "The hash value computed will be the ordinal number of the GDR Candidate that is acting as GDR." I'm not sure what that sentence means, but then again, this entire document is way outside my area of expertise, so perhaps this is obvious. Nits/editorial comments: The IDNITS tool reports: == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Are those the addresses in 5.2.1? Are they kosher? In 5.3.2, why is it "RECOMMENDED that the addresses are sorted in descending order."? Is that what's mentioned in 5.4? If so, perhaps a forward reference would be helpful. Finally, my "interesting note": I see in the shepherd report: ---- (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, there is IPR and it has been declared with #1713. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, IPR has been declared and the WG has been notified. ---- That seems to indicate that nobody had any comment about the IPR declaration. But I also see noted in the shepherd report, "Cisco has an implementation of this protocol. No other vendors have indicated plan to implement the specification". That leads to a pretty obvious question: Are other vendors not implementing this because of the IPR (which you'd think would be a concern), or are other vendors planning on implementing this in the future, or is this just a Cisco-private extension that requires no interoperability? It seems curious that there was no discussion at all.