Pete, thanks for your review. I think the uses of normative language and the nits you identified are ok as-is, but would encourage the authors to take a look. Alissa > On Nov 5, 2019, at 6:58 PM, Pete Resnick via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Pete Resnick > Review result: Ready with Issues > > 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 > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > 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. > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
