Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-rfc6006bis-04

I have only reviewed the diffs from RFC6006 (Perhaps we should request tools support for bis document diffs):
<https://www.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc6006.txt&url2=draft-ietf-pce-rfc6006bis-03>

The instructions in section 6.5 only indicate that IANA should update the document reference. The changes indicated in this section additionally reserve new values (specifically, the object type of "0" for object classes 28-31). As these changes are not called out, they run the risk of being overlooked. Please update the instructions to IANA to indicate that the registered values have changed, not just the document references.

I don't object the publication of this document.

However, I want to call attention to the latest IPR declaration [1] which seems to have resulted in a very, very, very late claim against this document *and* rfc6006.  Not only was the declaration done recently, but I don't think the WG was explicitly made aware of it.  I did look at the archive and this is what I found:

- WG Chair asked the authors to update the system to reflect that the IPR claimed against rfc6006 also applies to this document [2]

- a new IPR statement [1] was filed, which updated the previous one [3]

The problem is that the most recent statement [1] points to a patent ("US 12/404100") which is different from the one in the original statement [3] ("US 12/708048").  I take this update to mean that there is more IP than originally claimed -- resulting in a very, very, very late statement.  Note that it came in after the WGLC concluded and just a couple of days before the document was submitted to the IESG for Publication.

I'll let the WG chairs and the responsible AD take appropriate actions.

[1] https://datatracker.ietf.org/ipr/2983/ 
[2] https://mailarchive.ietf.org/arch/msg/pce/4rxUbSO16PU22ThiMHBf66M73yA/?qid=222caa9caf467838c3c40466e1de7e7e 
[3] https://datatracker.ietf.org/ipr/1686/

Is section 2 expected to be of more than background interest to an implementer? If not, I suggest moving it to an appendix, or at least towards the back of the document.

- Where is the "diff from RFC6006" section?
The following is not useful:

       This document obsoletes RFC 6006 and incorporates all outstanding
       Errata:

       o Erratum with IDs: 3819, 3830, 3836, 4867, and 4868.

I found "Appendix A. Summary of the RBNF Changes from RFC 6006", as a good start, but it doesn't even appear in the table of content. Why?

- I've not been following the IPR situation (as described by Alvaro), but would like to understand and it should be discussed during the telechat.
Is it the case that https://datatracker.ietf.org/ipr/1686/ (related to RFC6006) is updated by https://datatracker.ietf.org/ipr/2983/ (related to RFC6006 and RFC6006bis)?

Revising position after offline discussion

I support EKR's discuss.  MD5 should be deprecated by now.

I could be helpful, also for implementors to update their code, to more explicitly spell out what the changes are (in the intro) instead of just listing the errata numbers.

* Appendix A:

Did you mean "responses" instead of "requests" in this sentence?

"Update to the reply message to allow for bundling of multiple
      path computation requests..."

* I agree with Benoit and Mirja that summarizing all the changes since RFC6006 would be useful (Thanks for doing this for the RBNF!)