Last Call Review of draft-ietf-pim-drlb-13
review-ietf-pim-drlb-13-genart-lc-resnick-2019-11-05-00

Request Review of draft-ietf-pim-drlb
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-11-07
Requested 2019-10-24
Authors Yiqun Cai, Heidi Ou, Sri Vallepalli, mankamana mishra, Stig Venaas, Andy Green
Draft last updated 2019-11-05
Completed reviews Rtgdir Last Call review of -13 by Ben Niven-Jenkins (diff)
Genart Last Call review of -13 by Pete Resnick (diff)
Secdir Last Call review of -13 by Carl Wallace (diff)
Tsvart Last Call review of -13 by Michael Scharf (diff)
Opsdir Last Call review of -13 by Joe Clarke (diff)
Assignment Reviewer Pete Resnick
State Completed
Review review-ietf-pim-drlb-13-genart-lc-resnick-2019-11-05
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/wJqeFvEbkB8MdA-nwzHiGw42_b4
Reviewed rev. 13 (document currently at 14)
Review result Ready with Issues
Review completed: 2019-11-05

Review
review-ietf-pim-drlb-13-genart-lc-resnick-2019-11-05

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.