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

From: Alissa Cooper <[email-masked]>
Date: Tue, 3 Dec 2019 12:54:42 -0500

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art