Subject: [pim] Genart last call review of draft-ietf-pim-drlb-13

From: Pete Resnick via Datatracker <[email-masked]>
Date: Tue, 05 Nov 2019 15:58:50 -0800

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.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 7 Nov 2019 08:35:38 -0800

On November 5, 2019 at 6:58:52 PM, Pete Resnick wrote:

Pete:

Hi!

> that there was no discussion at all.

Not having discussions about IPR is normal in the Routing Area.  I
would consider having a discussion about it curious. ;-)

The sentence you quoted above from the Shepherd report is incomplete,
it says: “No other vendors have indicated plan to implement the
specification but they support publication of this draft.”  I don’t
know the reasons why other vendors are not implementing — another
obvious possibility is simply that they don’t have immediate customer
demand.  The WG is cc’d, so someone may want to chime in.

The extension in this draft requires signaling and coordination
between multiple routers; the dynamic nature of agreeing on which
router is the GDR is what requires interoperability between the
different routers.  This type of load balancing can be useful wherever
multiple PIM DRs exist, so I don’t think it can be considered a
private extension, or applicable only in single-vendor deployments.

Thanks for the careful review and for including interesting notes.

Alvaro.

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 08 Nov 2019 07:49:55 -0600

Hi Alvaro,

On 7 Nov 2019, at 10:35, Alvaro Retana wrote:

>> specification".

Heh.

> specification but they support publication of this draft.”

Well, the statement that someone "supports publication of this draft" I 
always take as a NOOP. Do they support publication because they like the 
author and think the author should have more publications? Or because 
they think the writing is poetic? Or because they want the author to 
support their own draft next time? Why would they support publication if 
they have no plans to implement it?

> I don’t
> demand.

Sure, if they think eventually there will be demand and that they'll 
implement later, that's a fine reason, and that would indicate that they 
don't think they'll have any IPR worries later. That said, the IPR 
declaration for this document still shows, "Licensing Declaration to be 
Provided Later"; perhaps everybody is fine with RAND for this case.

> private extension, or applicable only in single-vendor deployments.

If only one vendor implements this and everybody else ignores it, it 
still works, right?

> Thanks for the careful review and for including interesting notes.

Always willing to cause interesting discussion. :-)

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best