Thanks, Tom. Regards! -Qin -----邮件原件----- 发件人: Tom Taylor [mailto:[email protected]] 发送时间: 2014年7月7日 17:39 收件人: Qin Wu; [email protected]; [email protected]; 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:[email protected]] > 发送时间: 2014年7月7日 10:37 > 收件人: [email protected]; > [email protected]; 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" > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
