Skip to main content

Last Call Review of draft-ietf-xrblock-rtcp-xr-psi-decodability-04
review-ietf-xrblock-rtcp-xr-psi-decodability-04-genart-lc-taylor-2014-07-07-00

Request Review of draft-ietf-xrblock-rtcp-xr-psi-decodability
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-07-07
Requested 2014-06-26
Authors Jiangang Tong, Claire Bi, Roni Even , Qin Wu , Rachel Huang
I-D last updated 2014-07-07
Completed reviews Genart Last Call review of -04 by Tom Taylor (diff)
Secdir Last Call review of -04 by Hilarie Orman (diff)
Assignment Reviewer Tom Taylor
State Completed
Request Last Call review on draft-ietf-xrblock-rtcp-xr-psi-decodability by General Area Review Team (Gen-ART) Assigned
Reviewed revision 04 (document currently at 07)
Result Ready w/issues
Completed 2014-07-07
review-ietf-xrblock-rtcp-xr-psi-decodability-04-genart-lc-taylor-2014-07-07-00
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-xrblock-rtcp-xr-psi-decodability-04
Reviewer: Tom Taylor
Review Date: 6 July 2014
IETF LC End Date: 7 July 2014
IESG Telechat date: (not known)



Summary: basically ready with very minor issues and a number of 


editorial suggestions.




Major issues: none.

Minor issues:



(1) It might be helpful to add text in Section 3 explaining that 


PAT_error_2_count and PMT_error_2_count are actually replacements for 


and improvements on PAT_error_count and PMT_error_count respectively and 


are therefore preferred in future implementations.






(2) Condition (2) of PAT_error_2_count: "one table with table_id other 


than 0x00" is more precise than intended by [ETSI]. s/one/a/. This 


comment also applies to PMT_error_2_count (third from last line of first 


paragraph) and CAT_error_count (both conditions).




Nits/editorial comments:



General: blanks are missing in a number of places, typically following a 


comma or preceding a parenthesis.




Abstract
--------



  "statistics metrics" seems a bit redundant, but I wonder if "metric" 


has a special meaning to people working in this area. To me, "metric" is 


another word for "measurement result". So its use to describe the 


contents of the XR block makes sense. However, when we get to Section 3, 


"metric" is used in place of "indicator". Is that really correct usage?




  s/Program specific information/Program Specific Information/

Section 1.1
-----------


Some redundancy with the opening paragraph of 1.1, some cramming 


together of different ideas. Suggested alternative:




OLD

   This memo is based on information consistency tests and resulting
   indicators defined by ETSI [ETSI] and defines a new block type to
   augment those defined in [RFC3611] for use with MPEG2 Transport
   Stream (TS) [ISO-IEC.13818-1.2007].  The new block type supports
   reporting of the number of occurrences of each Program Specific
   Information (PSI) indicator in the first and second priorities that
   supplements information from PSI independent Decodability Statistics
   Metrics Block [RFC6990]; third priority indicators are not supported.

NEW

   This memo defines a new block type for use with MPEG2 Transport
   Stream (TS) [ISO-IEC.13818-1.2007], to
   augment those defined in [RFC3611].  The new block type supports
   reporting of the number of occurrences of each Program Specific
   Information (PSI) indicator in the first and second priorities listed
   by [ETSI] sections 5.2.1 and 5.2.2 respectively.  Third priority
   indicators are not supported. The metrics defined here
   supplement information from the PSI-independent Decodability
   Statistics Metrics Block [RFC6990].

Section 1.2
-----------
s/defined/defines/ on second line for consistency with the other sentences.

Section 1.3
-----------
s/Architectures [RFC6792]/Architecture [RFC6792]/
s/guideline/guidelines/


s/for reporting block format using RTCP XR/for RTCP XR reporting block 


formats/




Section 1.4
-----------
s/;/,/ on second line.
s/;/./ on third-last line.

Section 3
---------


See remark on use of "metric" above (Section 1.1). Could the first 


sentence be rewritten:




OLD

   ETSI TR 101290 [ETSI] generally defines metrics related to error
   events while this document contains counts of those metrics defined
   in [ETSI].

NEW

   ETSI TR 101290 [ETSI] generally defines indicators related to error
   events, while the XR block defined in this document contains counts
   of occurrences of the [ETSI] indicators.

Fifth line: s/PSI independent/PSI-independent/ (add hyphen)

Paragraph below the CRC and CAT bullets:


 (1) What do you mean by: "scrambling may be considered"? Do you mean 


that the presence or absence of scrambling is part of the error 


checking, or something else?


 (2) I'd suggest expanding "The other parameters ..." to "The other 


parameters defined in [ETSI] Section 5 [or whatever scope you intended] 


but not listed above ...".




Section 3, PID_Error_Count
--------------------------
Second sentence is not quite accurate. It should read:

OLD

      A PID_error occurs when MPEG TS streams
      are remultiplexed and any PID doesn't refer to an actual data
      stream, as defined in the section 5.2.1 of [ETSI]

NEW
      A PID error occurs [is indicated?] when no data stream is present
      corresponding to a given PID. This may be caused by multiplexing
      or demultiplexing, then remultiplexing.  See
      section 5.2.1 of [ETSI].