[Gen-art] Genart last call review of draft-ietf-pim-drlb-13

[Pete Resnick via Datatracker <[e-mail]>]

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.