Subject: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-psi-decodability-03

From: Alissa Cooper <[email-masked]>
Date: Tue, 03 Jun 2014 15:08:15 -0600

I have reviewed this draft in preparation for IETF LC and I have some
questions before proceeding with the LC announcement.

In Section 3, there seem to be some inconsistencies between the way that
some of the fields are defined in the block and the way the corresponding
metrics are described in ETSI TR 101 290 (assuming
http://www.etsi.org/deliver/etsi_tr/101200_101299/101290/01.02.01_60/tr_101
290v010201p.pdf is the correct reference for that document):

(1) PAT_error_count is defined in the draft as:

"A count of the number of PAT errors that occurred in the above
      sequence number interval.  The program association table (PAT) is
      the only packet with packet ID (PID) 0x 0000.  A PAT error occurs
      when it does not occur at least every 0.5s or the table has an ID
      other than 0x 00, as defined in section 5.2.1 of [ETSI].  Every
      program within the MPEG TS stream is listed in the PAT; if it is
      missing, then no programs can be decoded."

Whereas in the ETSI document, a PAT_error is defined as:

"PID 0x0000 does not occur at least every 0,5 s
a PID 0x0000 does not contain a table_id 0x00 ( i.e.
a PAT)
Scrambling_control_field is not 00 for PID 0x0000”

Is the definition in the draft supposed to be equivalent to the first two
conditions in the ETSI definition? If so, that is not quite clear from the
draft. Why is the Scrambling_control_field condition not also part of the
definition in the draft?

I have the same questions about PAT_error_2_count.

(2) In the draft, PMT_error_count and PMT_error_2_count have the exact
same definition. But in the ETSI document, a PMT_error is different from a
PMT_error_2. Here are the definitions from the ETSI document:

PMT_error:
"Sections with table_id 0x02, ( i. e. a PMT), do not
occur at least every 0,5 s on the PID which is
referred to in the PAT
Scrambling_control_field is not 00 for all PIDs
containing sections with table_id 0x02 (i.e. a PMT)”

PMT_error_2:
"Sections with table_id 0x02, (i.e. a PMT), do not
occur at least every 0,5 s on each
program_map_PID which is referred to in the PAT
Scrambling_control_field is not 00 for all packets
containing information of sections with table_id
0x02 (i.e. a PMT) on each program_map_PID
which is referred to in the PAT"

Are the equivalent definitions of PMT_error_count and PMT_error_2_count in
the draft intentional? If so, why define the same metric twice, and why
make PMT_error_2_count different from the way PMT_error_2 is defined in
the ETSI document?

(3) The draft defines PID_error_count as:

"A count of the number of PID_errors that occurred in the above
      sequence number interval.  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.2 of [ETSI]."

PID_error is defined in 5.2.1 of the ETSI draft, not 5.2.2. Is the
definition in 5.2.1 what this field in the block is supposed to correspond
to, or is it something else?

(4) CAT_error_count is defined in the draft as:

"A count of the number of CAT_errors that occurred in the above
      sequence number interval.  A CAT_error occurs when the table has
      an ID other than 0x 01,as defined in the section 5.2.2 of [ETSI].”

CAT_error is defined in the ETSI document as:

"Packets with transport_scrambling_control not 00
present, but no section with table_id = 0x01 (i.e. a
CAT) present
Section with table_id other than 0x01
(i.e. not a CAT) found on PID 0x0001"

Again I’m curious why the definition in the draft seems to have only one
portion of one of the conditions that appear in the ETSI document.

Thanks,
Alissa

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Jun 2014 04:33:16 +0000

Hi, Alissa:
Thanks for valuable comments. We think not all implementations support scrambling and scrambling adds a lot of complexity for packet processing since it needs to support encryption and decryption.
But you are right, to get consistent with ETSI TR 101 290, I am okay with adding scrambling feature.
For your comments, please see my reply below.

Regards!
-Qin
-----邮件原件-----
发件人: xrblock [mailto:[email-masked]] 代表 Alissa Cooper
发送时间: 2014年6月4日 5:08
收件人: [email-masked]
主题: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-psi-decodability-03

I have reviewed this draft in preparation for IETF LC and I have some questions before proceeding with the LC announcement.

In Section 3, there seem to be some inconsistencies between the way that some of the fields are defined in the block and the way the corresponding metrics are described in ETSI TR 101 290 (assuming
http://www.etsi.org/deliver/etsi_tr/101200_101299/101290/01.02.01_60/tr_101
290v010201p.pdf is the correct reference for that document):

"PID 0x0000 does not occur at least every 0,5 s a PID 0x0000 does not contain a table_id 0x00 ( i.e.
a PAT)
Scrambling_control_field is not 00 for PID 0x0000”

Is the definition in the draft supposed to be equivalent to the first two conditions in the ETSI definition? If so, that is not quite clear from the draft. Why is the Scrambling_control_field condition not also part of the definition in the draft?

[Qin]: I propose the following change:
NEW TEXT:
"
   PAT_error_count: 16 bits

      A count of the number of PAT errors that occurred in the above
      sequence number interval.  The program association table (PAT) is
      the only packet with packet ID (PID) 0x 0000.  A PAT error occurs
      when it does not occur at least every 0.5s or the table has an ID
      other than 0x00 or Scrambling_control_field in the TS packet header
       is not 00 for PID 0x0000, as defined in section 5.2.1 of [ETSI].  Every
      program within the MPEG TS stream is listed in the PAT; if it is
      missing, then no programs can be decoded.
"

[Qin]:How about the following change:
NEW TEXT:
"
   PAT_error_2_count: 16 bits

      A count of the number of PAT2 errors that occurred in the above
      sequence number interval.  A PAT2 error occurs when it does not
      occur at least every 0.5s or the table has an ID other than 0x00
      or there is more than one table ID 0x 00 inside the packet with
      the PAT PID or Scrambling_control_field in the TS packet header 
      is not 00 for PID 0x0000, as defined in section 5.2.1 of [ETSI].
"

(2) In the draft, PMT_error_count and PMT_error_2_count have the exact same definition. But in the ETSI document, a PMT_error is different from a PMT_error_2. Here are the definitions from the ETSI document:

PMT_error:
"Sections with table_id 0x02, ( i. e. a PMT), do not occur at least every 0,5 s on the PID which is referred to in the PAT Scrambling_control_field is not 00 for all PIDs containing sections with table_id 0x02 (i.e. a PMT)”

PMT_error_2:
"Sections with table_id 0x02, (i.e. a PMT), do not occur at least every 0,5 s on each program_map_PID which is referred to in the PAT Scrambling_control_field is not 00 for all packets containing information of sections with table_id
0x02 (i.e. a PMT) on each program_map_PID which is referred to in the PAT"

Are the equivalent definitions of PMT_error_count and PMT_error_2_count in the draft intentional? If so, why define the same metric twice, and why make PMT_error_2_count different from the way PMT_error_2 is defined in the ETSI document?

[Qin]: Good catch, without scrambling, definitions of PMT_error_count and PMT_error_2_count in the draft are equivalent.
But in ETSI document, PMT_error_2_count is different from PMT_error_count since the former excludes specifically network_PID.
I propose the following changes to definitions of PMT_error_count and PMT_error_2_count in the draft:
NEW TEXT:
"
   PMT_error_count: 16 bits

      A count of the number of PMT_errors that occurred in the above
      sequence number interval.  A PMT_error occurs when the program map
      table (PMT) does not come up at least every 0.5s on the PID that
      is referred to in the PAT or Scrambling_control_field in the TS packet header is not 00 for all PIDs
      containing sections with table_id 0x02 (i.e. a PMT), as defined in the section 5.2.1 of
      [ETSI].

      The measured value is unsigned value.  If the measurement is
      unavailable, the value 0xFFFF MUST be reported.  Note that
      PMT_error_count and PMT_error_2_count MUST NOT be reported at the
      same time in the same metric block.  If PMT_error_count is
      reported, PMT_error_2_count MUST be set to 0xFFFF.

   PMT_error_2_count: 16 bits

      A count of the number of PMT2 errors that occurred in the above
      sequence number interval.  A PMT2_error occurs when the program
      map table (PMT) does not come up at least every 0.5s on the PID
      that is referred to in the PAT or Scrambling_control_field in the TS packet header is not 00 for all packets
      containing information of sections with table_id
      0x02 (i.e. a PMT) on each program_map_PID
      which is referred to in the PAT, as defined in the section 5.2.1 of
      [ETSI].

      The measured value is unsigned value.  If the measurement is
      unavailable, the value 0xFFFF MUST be reported.  Note that
      PMT_error_count and PMT_error_2_count MUST NOT be reported at the
      same time in the same metric block.  If PMT_error_2_count is
      reported, PMT_error_count MUST be set to 0xFFFF.
"

PID_error is defined in 5.2.1 of the ETSI draft, not 5.2.2. Is the definition in 5.2.1 what this field in the block is supposed to correspond to, or is it something else?

[Qin]:Good catch, it should be 5.2.1.

"Packets with transport_scrambling_control not 00 present, but no section with table_id = 0x01 (i.e. a
CAT) present
Section with table_id other than 0x01
(i.e. not a CAT) found on PID 0x0001"

[Qin]: How about the following change:
NEW TEXT:
"
   CAT_error_count: 16 bits

      A count of the number of CAT_errors that occurred in the above
      sequence number interval.  A CAT_error occurs when the table has
      an ID other than 0x 01 or section with table_id = 0x01 (i.e. a
      CAT)is not present when scrambling is employed,as defined in the section 5.2.2 of [ETSI].
"

Again I’m curious why the definition in the draft seems to have only one portion of one of the conditions that appear in the ETSI document.

[Qin]: Addressed with the above proposed changes. Thanks.

Thanks,
Alissa

_______________________________________________
xrblock mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xrblock

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 4 Jun 2014 10:08:13 +0000

Thanks, Alissa for the careful review. 

Maybe a short paragraph that explains the differences between implementations that support and do not support scrambling (flag values, relevant field) would be useful. 

It looks to me that - if the edits proposals are to be included - it would be good to update the I-D and let the WG a few days to read and comment before sending the I-D  to IETF LC. 

Regards,

Dan

> -----Original Message-----
> From: xrblock [mailto:[email-masked]] On Behalf Of Qin Wu
> Sent: Wednesday, June 04, 2014 7:33 AM
> To: Alissa Cooper; [email-masked]
> Subject: Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-psi-
> decodability-03
> 
> Hi, Alissa:
> Thanks for valuable comments. We think not all implementations support
> scrambling and scrambling adds a lot of complexity for packet processing
> since it needs to support encryption and decryption.
> conditions in the ETSI definition? If so, that is not quite clear from the draft.
> Why is the Scrambling_control_field condition not also part of the definition
> in the draft?
> 
> "Sections with table_id 0x02, ( i. e. a PMT), do not occur at least every 0,5 s
> on the PID which is referred to in the PAT Scrambling_control_field is not 00
> for all PIDs containing sections with table_id 0x02 (i.e. a PMT)”
> 
> PMT_error_2:
> "Sections with table_id 0x02, (i.e. a PMT), do not occur at least every 0,5 s on
> each program_map_PID which is referred to in the PAT
> Scrambling_control_field is not 00 for all packets containing information of
> sections with table_id
> Are the equivalent definitions of PMT_error_count and PMT_error_2_count
> in the draft intentional? If so, why define the same metric twice, and why
> [Qin]: Good catch, without scrambling, definitions of PMT_error_count and
> PMT_error_2_count in the draft are equivalent.
> But in ETSI document, PMT_error_2_count is different from
> PMT_error_count since the former excludes specifically network_PID.
> PID_error is defined in 5.2.1 of the ETSI draft, not 5.2.2. Is the definition in
> 5.2.1 what this field in the block is supposed to correspond to, or is it
> something else?
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 5 Jun 2014 01:53:42 +0000

Hi,Dan:
Do we really need to distinguish implementation that support scrambling from implementation that don't?
For implementation that don't support scrambling, the error count due to employing scrambling in each related metric can be set to zero.
Take PAT_error_count as an example,
A PAT error occurs when it meets any one of the following three conditions
1. when PAT does not occur at least every 0.5s
2.the table has an ID other than 0x00 
3. Scrambling_control_field in the TS packet header
  is not 00 for PID 0x0000, as defined in section 5.2.1 of [ETSI].

The error count is sum of error count due to either condition listed above. The error count due to the 3rd condition can be set to zero 
when implementation doesn't support scrambling.
Whether scrambling is supported or not, Scrambling_control_field needs to be present in the TS packet and set an appropriate value.

So I think using a new flag bit to make distinction is not necessary since each scrambling related metric only conside scrambling related condition as one of possible condition.
For implementation that don't support scrambling, there is no error being counted due to scrambling being applied.

I will update the draft if you agree with the proposed changes.

Regards!
-Qin
-----邮件原件-----
发件人: Romascanu, Dan (Dan) [mailto:[email-masked]] 
发送时间: 2014年6月4日 18:08
收件人: Qin Wu; Alissa Cooper; [email-masked]
主题: RE: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-psi-decodability-03

Regards,

Dan

> scrambling and scrambling adds a lot of complexity for packet 
> processing since it needs to support encryption and decryption.
> 主题: [xrblock] AD evaluation: 
> draft-ietf-xrblock-rtcp-xr-psi-decodability-03
> 
> In Section 3, there seem to be some inconsistencies between the way 
> that some of the fields are defined in the block and the way the 
> corresponding metrics are described in ETSI TR 101 290 (assuming 
> http://www.etsi.org/deliver/etsi_tr/101200_101299/101290/01.02.01_60/t
> r_
> 101
> Is the definition in the draft supposed to be equivalent to the first 
> two conditions in the ETSI definition? If so, that is not quite clear from the draft.
> Why is the Scrambling_control_field condition not also part of the 
> definition in the draft?
> 
> same definition. But in the ETSI document, a PMT_error is different 
> from a PMT_error_2. Here are the definitions from the ETSI document:
> 
> PMT_error:
> "Sections with table_id 0x02, ( i. e. a PMT), do not occur at least 
> every 0,5 s on the PID which is referred to in the PAT 
> Scrambling_control_field is not 00 for all PIDs containing sections with table_id 0x02 (i.e. a PMT)”
> 
> PMT_error_2:
> "Sections with table_id 0x02, (i.e. a PMT), do not occur at least 
> every 0,5 s on each program_map_PID which is referred to in the PAT 
> Scrambling_control_field is not 00 for all packets containing 
> information of sections with table_id
> Are the equivalent definitions of PMT_error_count and 
> PMT_error_2_count in the draft intentional? If so, why define the same 
> metric twice, and why make PMT_error_2_count different from the way 
> PMT_error_2 is defined in the ETSI document?
> 
> [Qin]: Good catch, without scrambling, definitions of PMT_error_count 
> and PMT_error_2_count in the draft are equivalent.
>       that is referred to in the PAT or Scrambling_control_field in 
> the TS packet header is not 00 for all packets
> definition in
> 5.2.1 what this field in the block is supposed to correspond to, or is 
> it something else?
> 
>       CAT)is not present when scrambling is employed,as defined in the 
> section
> 5.2.2 of [ETSI].
> "
> 
> Again I’m curious why the definition in the draft seems to have only 
> one portion of one of the conditions that appear in the ETSI document.
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 04 Jun 2014 19:42:11 -0700

Hi Qin,

Thanks for your response. My comments are inline.

One note for the WG: I’m a little surprised that earlier reviews (e.g.,
during WGLC) did not catch some of these errors. For future documents of
this sort, it might be good to make sure that at least one reviewer or the
document shepherd does a comparison between what is specified in the I-D
and what is specified in other corresponding specs.

>adding scrambling feature.

I didn’t mean to take a position on the scrambling. But since it was not
addressed in the draft and references are made to the ETSI document, it
needs to be explained one way or the other. If the scrambling-based
conditions are not relevant, that should be explained; if they are part of
the logic that yields the errors, that should be explained.

>conditions in the ETSI definition? If so, that is not quite clear from
>the draft. Why is the Scrambling_control_field condition not also part of
>the definition in the draft?
>
>Every

I think this would be clearer if you break out the conditions:

PAT_error_count: 16 bits

      A count of the number of PAT errors that occurred in the above
sequence number interval.  The program association table (PAT) is the only
packet with packet ID (PID) 0x0000.  A PAT error occurs when: (1) a packet
with PID 0x0000 does not occur at least every 0.5 seconds, or (2) a packet
with PID 0x0000 does not contain a table_id 0x00 (i.e., a PAT), or (3) the
Scrambling_control_field in the TS packet header is not 00 for a packet
with PID 0x0000. See section 5.2.1 of [ETSI]. Every program within the
MPEG TS stream is listed in the PAT; if it is missing, then no programs
can be decoded.

I would suggest making similar changes to all of the field definitions
that describe a list of multiple conditions that trigger the errors.

>same definition. But in the ETSI document, a PMT_error is different from
>a PMT_error_2. Here are the definitions from the ETSI document:
>
>PMT_error:
>"Sections with table_id 0x02, ( i. e. a PMT), do not occur at least every
>0,5 s on the PID which is referred to in the PAT Scrambling_control_field
>is not 00 for all PIDs containing sections with table_id 0x02 (i.e. a
>PMT)”
>
>PMT_error_2:
>"Sections with table_id 0x02, (i.e. a PMT), do not occur at least every
>0,5 s on each program_map_PID which is referred to in the PAT
>Scrambling_control_field is not 00 for all packets containing information
>of sections with table_id
>in the draft intentional? If so, why define the same metric twice, and
>why make PMT_error_2_count different from the way PMT_error_2 is defined
>in the ETSI document?
>
>But in ETSI document, PMT_error_2_count is different from PMT_error_count
>since the former excludes specifically network_PID.
>      that is referred to in the PAT or Scrambling_control_field in the
>TS packet header is not 00 for all packets

If you can list the conditions as I suggest above, I think these are okay.

>definition in 5.2.1 what this field in the block is supposed to
>correspond to, or is it something else?
>
>section 5.2.2 of [ETSI].

In re-reading this, I’m actually not sure I understand the first condition
in the ETSI document and how it maps onto the error count being defined
here. Does a CAT_error occur when *any* packet has
transport_scrambling_control != 00 and no section with table_id==0x01? Is
CAT_error_count supposed to reflect the number of such packets that occur
within the (begin_seq, end_seq) interval?

Thanks,
Alissa

---

From: Qin Wu <[email-masked]>
Date: Thu, 5 Jun 2014 03:10:11 +0000

Hi, Alissa:
-----邮件原件-----
发件人: Alissa Cooper [mailto:[email-masked]] 
发送时间: 2014年6月5日 10:42
收件人: Qin Wu; [email-masked]
主题: Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-psi-decodability-03

Hi Qin,

One note for the WG: I’m a little surprised that earlier reviews (e.g., during WGLC) did not catch some of these errors. For future documents of this sort, it might be good to make sure that at least one reviewer or the document shepherd does a comparison between what is specified in the I-D and what is specified in other corresponding specs.

>with adding scrambling feature.

I didn’t mean to take a position on the scrambling. But since it was not addressed in the draft and references are made to the ETSI document, it needs to be explained one way or the other. If the scrambling-based conditions are not relevant, that should be explained; if they are part of the logic that yields the errors, that should be explained.

[Qin]: I believe it is the latter.

>http://www.etsi.org/deliver/etsi_tr/101200_101299/101290/01.02.01_60/tr
>_10
>1
>two conditions in the ETSI definition? If so, that is not quite clear 
>from the draft. Why is the Scrambling_control_field condition not also 
>part of the definition in the draft?
>

PAT_error_count: 16 bits

      A count of the number of PAT errors that occurred in the above sequence number interval.  The program association table (PAT) is the only packet with packet ID (PID) 0x0000.  A PAT error occurs when: (1) a packet with PID 0x0000 does not occur at least every 0.5 seconds, or (2) a packet with PID 0x0000 does not contain a table_id 0x00 (i.e., a PAT), or (3) the Scrambling_control_field in the TS packet header is not 00 for a packet with PID 0x0000. See section 5.2.1 of [ETSI]. Every program within the MPEG TS stream is listed in the PAT; if it is missing, then no programs can be decoded.

[Qin]: Looks good.

I would suggest making similar changes to all of the field definitions that describe a list of multiple conditions that trigger the errors.

[Qin]: Okay.

>every
>0,5 s on the PID which is referred to in the PAT 
>why make PMT_error_2_count different from the way PMT_error_2 is 
>defined in the ETSI document?
>

[Qin]: Okay.

>      CAT)is not present when scrambling is employed,as defined in the 

In re-reading this, I’m actually not sure I understand the first condition in the ETSI document and how it maps onto the error count being defined here. Does a CAT_error occur when *any* packet has transport_scrambling_control != 00 and no section with table_id==0x01? Is CAT_error_count supposed to reflect the number of such packets that occur within the (begin_seq, end_seq) interval?

[Qin]: you may misunderstand here. CAT error is triggered by two condition.
The first condition is the table has an ID other than 0x 01
The second condition is CAT Table is not present when scrambling is employed.
Which is equivalent to what ETSI document said as follows:
"
Packets with transport_scrambling_control not 00
present, but no section with table_id = 0x01 (i.e. a
CAT) present
"
To clear ambiguity ,how about the following change:
"
       A count of the number of CAT_errors that occurred in the above
      sequence number interval.  A CAT_error occurs when: (1) the table has
      an ID other than 0x 01 or (2) section with table_id = 0x01 (i.e. a
      CAT)is not present when scrambling is employed(i.e., scrambling_control 
      field is set as a value other than 00), as defined in the 
      section 5.2.2 of [ETSI].
"

Thanks,
Alissa

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 Jun 2014 11:03:16 +0000

Hi Alissa,

Thanks again for the attentive review. To address your comment - the shepherd review (maybe other) did look at the ETSI definitions. This document does not represent c complete rendering of the capabilities made available of that specification, but a most commonly implemented subset, which is indicated by the text in section 3: 

> The other parameters are ignored since they do not apply to all MPEG2
   implementations.  For further information on these parameters, see
   [ETSI].

This probably deserved being more detailed - in the case of scrambling, the error was to not consider scrambling, or at least to not make clear that it is left out. I personally am happy with the latest proposal suggested by Qin. 

Regards,

Dan

> From: xrblock [mailto:[email-masked]] On Behalf Of Alissa Cooper
> Sent: Thursday, June 05, 2014 5:42 AM
> To: Qin Wu; [email-masked]
> One note for the WG: I’m a little surprised that earlier reviews (e.g., during
> WGLC) did not catch some of these errors. For future documents of this sort,
> it might be good to make sure that at least one reviewer or the document
> shepherd does a comparison between what is specified in the I-D and what is
> specified in other corresponding specs.
> 
> conditions are not relevant, that should be explained; if they are part of the
> logic that yields the errors, that should be explained.
> 
>       A count of the number of PAT errors that occurred in the above sequence
> number interval.  The program association table (PAT) is the only packet with
> packet ID (PID) 0x0000.  A PAT error occurs when: (1) a packet with PID
> 0x0000 does not occur at least every 0.5 seconds, or (2) a packet with PID
> 0x0000 does not contain a table_id 0x00 (i.e., a PAT), or (3) the
> Scrambling_control_field in the TS packet header is not 00 for a packet with
> PID 0x0000. See section 5.2.1 of [ETSI]. Every program within the MPEG TS
> stream is listed in the PAT; if it is missing, then no programs can be decoded.
> 
> 
> I would suggest making similar changes to all of the field definitions that
> describe a list of multiple conditions that trigger the errors.
> 
> 
> 
> 
> 
> 
> 
> 
> >
> PMT_error_2_count
> In re-reading this, I’m actually not sure I understand the first condition in the
> ETSI document and how it maps onto the error count being defined here.
> Does a CAT_error occur when *any* packet has

---

From: Qin Wu <[email-masked]>
Date: Fri, 6 Jun 2014 06:27:53 +0000

Hi,
Dan is right, we didn't consider scrambling. However some error may be counted due to scrambling being applied.
To make the text in section more clear, we propose the following change.
NEW TEXT:
"
   In these parameters, scrambling may be considered. The other parameters are ignored since they do not apply to all MPEG2
   implementations.  For further information on these parameters, see
   [ETSI].
"
I will issue a new version soon based on our discussion so far. 

Regards!
-Qin
-----邮件原件-----
发件人: xrblock [mailto:[email-masked]] 代表 Romascanu, Dan (Dan)
发送时间: 2014年6月5日 19:03
收件人: Alissa Cooper; Qin Wu; [email-masked]
主题: Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-psi-decodability-03

Hi Alissa,

Regards,

Dan

> WGLC) did not catch some of these errors. For future documents of this 
> sort, it might be good to make sure that at least one reviewer or the 
> document shepherd does a comparison between what is specified in the 
> I-D and what is specified in other corresponding specs.
> 
> >Thanks for valuable comments. We think not all implementations 
> >support scrambling and scrambling adds a lot of complexity for packet 
> I didn’t mean to take a position on the scrambling. But since it was 
> not addressed in the draft and references are made to the ETSI 
> document, it needs to be explained one way or the other. If the 
> scrambling-based conditions are not relevant, that should be 
> explained; if they are part of the logic that yields the errors, that should be explained.
> 
> >from the draft. Why is the Scrambling_control_field condition not 
> >also part of the definition in the draft?
> >
> sequence number interval.  The program association table (PAT) is the 
> only packet with packet ID (PID) 0x0000.  A PAT error occurs when: (1) 
> a packet with PID
> Scrambling_control_field in the TS packet header is not 00 for a 
> packet with PID 0x0000. See section 5.2.1 of [ETSI]. Every program 
> within the MPEG TS stream is listed in the PAT; if it is missing, then no programs can be decoded.
> 
> 
> >(2) In the draft, PMT_error_count and PMT_error_2_count have the 
> >exact same definition. But in the ETSI document, a PMT_error is 
> >different from a PMT_error_2. Here are the definitions from the ETSI document:
> >
> >PMT_error:
> >in the draft intentional? If so, why define the same metric twice, 
> >and why make PMT_error_2_count different from the way PMT_error_2 is 
> >Section with table_id other than 0x01 (i.e. not a CAT) found on PID 
> >0x0001"
> >
> In re-reading this, I’m actually not sure I understand the first 
> condition in the ETSI document and how it maps onto the error count being defined here.
> transport_scrambling_control != 00 and no section with table_id==0x01? 
> Is CAT_error_count supposed to reflect the number of such packets that 
> occur within the (begin_seq, end_seq) interval?
> 
> Thanks,
> Alissa
> 
> 
> >

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 06 Jun 2014 14:39:50 -0700

On 6/5/14, 4:03 AM, "Romascanu, Dan (Dan)" <[email-masked]> wrote:

>Hi Alissa,
>
>Thanks again for the attentive review. To address your comment - the
>shepherd review (maybe other) did look at the ETSI definitions. This
>document does not represent c complete rendering of the capabilities made
>available of that specification, but a most commonly implemented subset,
>which is indicated by the text in section 3:
>
>This probably deserved being more detailed - in the case of scrambling,
>the error was to not consider scrambling, or at least to not make clear
>that it is left out.

Fair enough. I had not interpreted that original section 3 text to cover
these scrambling conditions.
Alissa

>I personally am happy with the latest proposal suggested by Qin.
>
>Regards,
>
>Dan
>
>
>>during
>>sort,
>>sequence
>>with
>>that
>>condition in the
>>Is