ietf
[Top] [All Lists]

RE: Gen-ART IETF LC review of draft-ietf-xrblock-rtcp-xr-psi-decodability-04

2014-07-07 10:33:56
Thanks, Tom.

Regards!
-Qin
-----邮件原件-----
发件人: Tom Taylor [mailto:tom(_dot_)taylor(_dot_)stds(_at_)gmail(_dot_)com] 
发送时间: 2014年7月7日 17:39
收件人: Qin Wu; xrblock-chairs(_at_)tools(_dot_)ietf(_dot_)org; 
draft-ietf-xrblock-rtcp-xr-psi-decodability(_at_)tools(_dot_)ietf(_dot_)org; 
Alissa Cooper; Gen Art; The IETF
主题: Re: Gen-ART IETF LC review of draft-ietf-xrblock-rtcp-xr-psi-decodability-04

I'm happy with your responses.

Tom

On 07/07/2014 1:50 AM, Qin Wu wrote:
Hi, Tom:
Thanks for your valuable review.
See my reply inline.

Regards!
-Qin
-----邮件原件-----
发件人: Tom Taylor [mailto:tom(_dot_)taylor(_dot_)stds(_at_)gmail(_dot_)com]
发送时间: 2014年7月7日 10:37
收件人: xrblock-chairs(_at_)tools(_dot_)ietf(_dot_)org; 
draft-ietf-xrblock-rtcp-xr-psi-decodability(_at_)tools(_dot_)ietf(_dot_)org; 
Alissa 
Cooper; Gen Art; The IETF
主题: Gen-ART IETF LC review of 
draft-ietf-xrblock-rtcp-xr-psi-decodability-04

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.

[Qin]: Okay.

(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).

[Qin]:Accepted.

Nits/editorial comments:

General: blanks are missing in a number of places, typically following a 
comma or preceding a parenthesis.

[Qin]: Okay.

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?

[Qin]: To avoid confusion, we can make the following change OLD TEXT:
"
    ETSI TR 101290 [ETSI] generally defines metrics related to error
    events while this document contains counts of those metrics defined
    in [ETSI].
"
NEW TEXT:
"
    ETSI TR 101290 [ETSI] generally defines parameters related to error
    events while this document contains counts of those parameters defined
    in [ETSI].
"

    s/Program specific information/Program Specific Information/

[Qin]:Okay.

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].


[Qin]: Accepted.

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

[Qin]: Okay.
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/

[Qin]:Okay.

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

[Qin]: Okay.
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.

[Qin]: I am okay with this proposed change.

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

[Qin]: Okay.

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?


[Qin]: This sentence did introduce a few confusion, what about the following 
change:
NEW TEXT:
"
Measurement results for some of these parameters (e.g.,PAT error or 
PMT error) may be different based on whether scrambling is employed "

   (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 ...".

[Qin]: Okay.

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].

[Qin]: Accepted. For consistency, we prefer to use 'occurs' instead of "is 
indicated"


<Prev in Thread] Current Thread [Next in Thread>