I have reviewed draft-ietf-payload-rtp-h265-13 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.   Short Summary This document specifies RTP Payload format for H.265. there are no operational or management concerns in this document. I believe it is ready for publication with tiny nits. I also have a few minor comments which authors of this document might consider.   1.Section 1.1.1, in-loop filtering bullet Suggest to add a short name “DBF” for deblocking filter and provide a reference to it. 2.Section 1.1.1, in-loop filtering bullet Suggest to give a definition for de-ring filter or add a reference to it. In addition, it is better to have a consistent term, e.g., deblocking and deringomg or de-blocking and de-ringing 3.Section 1.1.2, 1st paragraph said “ In the following, a list of differences in these aspects compared to H.264 is summarized. …… ” The introduction is too long, Would it be great to have this non-normative part on difference between H.264 and H.265 moving to appendix of this document And add an anchor point pointing to the appendix. 4.Section 1.1.2 Suggest to add a short name for picture order count   5.Section 1.1.3 , 1st paragraph said: “ The reportedly significantly higher encoding computational demand    of HEVC over H.264, in conjunction with the ever increasing video    resolution (both spatially and temporally) required by the    market ” Is this marketing promotion? Is there any other technical reason for that? Suggest to remove “required by the market”. 6.Section 1.1.3, 2nd paragraph said: “ Specifically, for parallelization, four    picture partition strategies are available. ” What are four picture partition strategies? Where are they specified? 7.Section 1.1.4 said: “    TID: 3 bits      nuh_temporal_id_plus1.  This field specifies the temporal       identifier of the NAL unit plus 1.  The value of TemporalId is       equal to TID minus 1.  ” is the temporal identifier TemporaId ? Is the temporal identifier a full name of TID? 8.Section 1.1.4 also said: “ A TID value of 0 is illegal to ensure       that there is at least one bit in the NAL unit header equal to       1, so to enable independent considerations of start code       emulations in the NAL unit header and in the NAL unit payload       data. ” Which bit is set to 1 in the NAL Unit Header? 9.Section 4.3 said: “ Informative Note: While this specification enables the use of   MRST within the H.265 RTP payload, the signaling of MRST within   SDP Offer/Answer is not fully specified at the time of this   writing. See [RFC5576] and [RFC5583] for what is supported   today as well as [I-D.ietf-avtcore-rtp-multi-stream] and [I-   D.ietf-mmusic-sdp-bundle-negotiation] for future directions.   ” It looks like an open issue? Would it be good to add a statement to replace this informative note, e.g., we can say how SDP Offer/Answer is extended to support signaling of MRST is a generic issue that should be tackled by [I-D.ietf-avtcore-rtp-multi-stream] and [I-D.ietf-mmusic-sdp-bundle-negotiation], is not in the scope of this document. 10.Section 4.3 also said: “ When an RTP stream A depends on another RTP stream B, the RTP stream B is referred to as a dependee RTP stream of the RTP stream A. ” Why have the last sentence when the definition of dependee RTP stream has already been given in the section 3.1.2? It seem the last sentence is redundant. 11.Section 7.2.5 Miss a blank space between “7.2.5” and “Dependency” in the title of section 7.2.5 12.Section 8.3,2nd paragraph said: “ even a decoded picture buffer size    of two would work for the approach described in the previous    paragraph. “   Buffer size of two? Two bytes or other buffer size in other unit? 13.Section 9, 3rd paragraph: I don’t understand the last part of this sentence, what does domain or presentation stand for in this context? How are they corresponding to parameters defined RTP payload format for H.264? Would it be great to add some explanation text to clarify this?   14.Run IDNits tool, it produce   Checking references for intended status: Proposed Standard   ----------------------------------------------------------------------------        (See RFCs 3967 and 4897 for information about using normative references      to lower-maturity documents in RFCs)     -- Looks like a reference, but probably isn't: '0' on line 1749     == Unused Reference: 'RFC6190' is defined on line 3841, but no explicit      reference was found in the text     == Unused Reference: 'I-D.ietf-mmusic-sdp-bundle-negotiation' is defined on      line 3878, but no explicit reference was found in the text     -- Possible downref: Non-RFC (?) normative reference: ref. 'HEVC'     == Outdated reference: A later version (-08) exists of      draft-ietf-avtcore-rtp-multi-stream-05     == Outdated reference: A later version (-23) exists of      draft-ietf-mmusic-sdp-bundle-negotiation-02     == Outdated reference: A later version (-08) exists of      draft-ietf-avtext-rtp-grouping-taxonomy-02   Best Regards! -Qin Wu