Digital cinema (D-cinema) operations — Part 5: Security log event class and constraints

ISO 26430-5:2009 specifies a Security Event Class and namespace for Security Log Records. It also constrains individual Log Records and sequences of such records (Log Reports) as they are used for security event logging purposes in D-cinema applications. The items covered contain descriptions of events logged by the security system, which are intended to provide forensic information regarding security critical events. ISO 26430-5:2009 does not specify the means of communication or the format of messaging between security devices in a system, nor does it define the format for storage of Log Events within the protected storage of a security device. The Security Log Records and Security Log Record Sequences (Log Reports) described herein are intended for the reporting of Security Events previously recorded by the security system to consumers of that information which are external to the security system.

Opérations du cinéma numérique (cinéma D) — Partie 5: Classe et contraintes d'événement du journal de sécurité

General Information

Status
Published
Publication Date
02-Dec-2009
Technical Committee
Drafting Committee
Current Stage
9093 - International Standard confirmed
Completion Date
17-Jan-2023
Ref Project

Buy Standard

Standard
ISO 26430-5:2009 - Digital cinema (D-cinema) operations
English language
24 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO 26430-5:2009 - Digital cinema (D-cinema) operations
English language
24 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 26430-5
First edition
2009-12-15
Digital cinema (D-cinema) operations —
Part 5:
Security log event class and constraints
Opérations du cinéma numérique (cinéma D) —
Partie 5: Classe et contraintes d'événement du journal de sécurité
Reference number
ISO 26430-5:2009(E)
ISO 2009
---------------------- Page: 1 ----------------------
ISO 26430-5:2009(E)
PDF disclaimer

This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but

shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In

downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat

accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.

Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation

parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In

the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

COPYRIGHT PROTECTED DOCUMENT
© ISO 2009

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,

electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or

ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2009 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 26430-5:2009(E)
Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies

(ISO member bodies). The work of preparing International Standards is normally carried out through ISO

technical committees. Each member body interested in a subject for which a technical committee has been

established has the right to be represented on that committee. International organizations, governmental and

non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the

International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of technical committees is to prepare International Standards. Draft International Standards

adopted by the technical committees are circulated to the member bodies for voting. Publication as an

International Standard requires approval by at least 75 % of the member bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent

rights. ISO shall not be held responsible for identifying any or all such patent rights.

ISO 26430-5 was prepared by the Society of Motion Picture and Television Engineers (as

SMPTE 430-5-2008) and was adopted, under a special “fast-track procedure”, by Technical Committee

ISO/TC 36, Cinematography, in parallel with its approval by the ISO member bodies.

ISO 26430 consists of the following parts, under the general title Digital cinema (D-cinema) operations:

⎯ Part 1: Key delivery message [equivalent to SMPTE 430-1]
⎯ Part 2: Digital certificate [equivalent to SMPTE 430-2]
⎯ Part 3: Generic extra-theater message format [equivalent to SMPTE 430-3]
⎯ Part 4: Log record format specification [equivalent to SMPTE 430-4]
⎯ Part 5: Security log event class and constraints [equivalent to SMPTE 430-5]

⎯ Part 6: Auditorium security messages for intra-theater communications [equivalent to SMPTE 430-6]

⎯ Part 9: Key delivery bundle [equivalent to SMPTE 430-9]
© ISO 2009 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 26430-5:2009(E)
SMPTE 430-5-2008
SMPTE STANDARD
D-Cinema Packaging —
Security Log Event
Class and Constraints
Page 1 of 25 pages
Table of Contents Page

Foreword ................................................................................................................................................. 2

Introduction ............................................................................................................................................. 2

1 Scope ................................................................................................................................................ 3

2 Conformance Notation ...................................................................................................................... 3

3 Normative References ...................................................................................................................... 3

4 Overview (Informative)..................................................................................................................... 4

5 Definitions ......................................................................................................................................... 5

5.1 Definition of Terms................................................................................................................... 5

5.2 Definition of Processes and Validation .................................................................................... 6

5.2.1 Composition Playlist Validity........................................................................................ 6

5.2.2 Frame Playback Process............................................................................................. 6

5.2.3 Complete CPL Playback.............................................................................................. 6

5.3 Security Event Class................................................................................................................ 6

5.4 Security Class Namespace...................................................................................................... 6

5.5 Namespace Prefixes................................................................................................................ 6

5.6 Reference Architectures .......................................................................................................... 7

6 Security Application Requirements................................................................................................... 7

6.1 Security Constraints................................................................................................................. 8

6.1.1 Log Record Header...................................................................................................... 8

6.1.2 Log Record Body ......................................................................................................... 8

6.1.3 Log Record Signature.................................................................................................. 9

6.2 Security Log Record Authentication and Chaining .................................................................. 10

7 Security Event Definitions ................................................................................................................. 10

7.1 ReferenceID Scope.................................................................................................................. 10

7.2 Event Types ............................................................................................................................. 11

7.3 Event Sub Types...................................................................................................................... 12

7.3.1 Playout Event Sub Types............................................................................................. 12

7.3.2 Validation Event Sub Types......................................................................................... 14

7.3.3 Key Event Sub Types .................................................................................................. 15

7.3.4 ASM Event Sub Types................................................................................................. 16

7.3.5 Operations Event Sub Types....................................................................................... 18

7.4 Exception Tokens and Definitions............................................................................................ 22

8 Examples (Informative) .................................................................................................................... 23

8.1 Example 1 ............................................................................................................................... 23

9 Glossary of Acronyms........................................................................................................................ 23

Annex A Proxy Logging (Informative) .................................................................................................. 24

Annex B Security Log Report Filtering (Informative) ........................................................................... 25

Copyright © 2008 by THE SOCIETY OF
Approved
MOTION PICTURE AND TELEVISION ENGINEERS
March 3, 2008
595 W. Hartsdale Ave., White Plains, NY 10607
(914) 761-1100
© ISO 2009 – All rights reserved 1
---------------------- Page: 4 ----------------------
ISO 26430-5:2009(E)
SMPTE 430-5-2008
Foreword

SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards

developing organization. Headquartered and incorporated in the United States of America, SMPTE has

members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards,

Recommended Practices and Engineering Guidelines, are prepared by SMPTE’s Technology Committees.

Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates

closely with other standards-developing organizations, including ISO, IEC and ITU.

SMPTE Engineering Documents are drafted in accordance with the rules given in Part XIII of its

Administrative Practices.
SMPTE Standard 430-5 was prepared by Technology Committee DC28.
Introduction

A general specification for D-Cinema Log Records and Log Reports is specified in [LogRecord]. This Security

Class standard defines a class, and an associated namespace, for Log Records for security logging.

Additionally, this standard constrains the use and application of that format to Security Log Records and

Reports. More specifically, this document specifies the format of Log Records produced by security devices

within D-Cinema systems. Typically these records are produced by the Security Manager component of the

system, which produces records of security events for consumption by systems external to the security

system. When the Security Manager produces these records, they are constructed to support authentication

and non-repudiation by and for the device that produces them. Support is included for authenticating chains of

records in a manner that reduces the overhead that would otherwise result if each record were to be

authenticated individually.
Page 2 of 25 pages
2 © ISO 2009 – All rights reserved
---------------------- Page: 5 ----------------------
ISO 26430-5:2009(E)
SMPTE 430-5-2008
1 Scope

The purpose of this document is to specify a Security Event Class and namespace for Security Log Records;

and to constrain individual Log Records and sequences of such records (Log Reports) as they are used for

security event logging purposes in D-Cinema applications. The items covered contain descriptions of events

logged by the security system, which are intended to provide forensic information regarding security critical

events. This document does not specify the means of communication or the format of messaging between

security devices in a system. Neither does this document define the format for storage of Log Events within

the protected storage of a security device. The Security Log Records and Security Log Record Sequences

(Log Reports) described herein are intended for reporting of Security Events previously recorded by the

security system to consumers of that information which are external to the security system.

2 Conformance Notation

Normative text is text that describes elements of the design that are indispensable or contains the

conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful

to the user, but not indispensable, and can be removed, changed, or added editorially without affecting

interoperability. Informative text does not contain any conformance keywords.

All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as

"Informative" or individual paragraphs that start with "Note:”

The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the

document and from which no deviation is permitted.

The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as

particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but

not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated

but not prohibited.

The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.

The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be

defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision

will never be defined in the future.

A conformant implementation according to this document is one that includes all mandatory provisions

("shall") and, if implemented, all recommended provisions ("should") as described. A conformant

implementation need not implement optional provisions ("may") and need not implement them as described.

3 Normative References

The following standards contain provisions which, through reference in this text, constitute provisions of this

standard. At the time of publication, the editions indicated were valid. All standards are subject to revision,

and parties to agreements based on this standard are encouraged to investigate the possibility of applying the

most recent edition of the standards indicated below.

[RFC 3280] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

URL: http://www.ietf.org/rfc/rfc3280.txt
[DCMLTypes] SMPTE 433-2008, XML Data Types for Digital Cinema)
[LogRecord] SMPTE 430-4-2008, Log Record Format Specification for D-Cinema
Page 3 of 25 pages
© ISO 2009 – All rights reserved 3
---------------------- Page: 6 ----------------------
ISO 26430-5:2009(E)
SMPTE 430-5-2008
[KDM] SMPTE 430-1-2006, D-Cinema Operations — Key Delivery Message
[D-Cert] SMPTE 430-2-2006 D-Cinema Operations — Digital Certificate

[ETM] SMPTE 430-3-2006, D-Cinema Operations — Generic Extra-Theater Message Format

[ASM] SMPTE 430-6-2008, D-Cinema Operations — Auditorium Security Messages for Intra-Theater

Communications
[TFE] SMPTE 429-6-2006, D-Cinema Packaging — MXF Track File Essence Encryption
[CPL] SMPTE 429-7-2006, D-Cinema Packaging — Composition Playlist
[PKL] SMPTE 429-8-2007, D-Cinema Packaging — Packing List
[TRK] SMPTE 429-3-2007, D-Cinema Packaging — Sound and Picture Track File

[RFC 4051] Additional XML Security Uniform Resource Identifiers (URIs) http://www.ietf.org/rfc/rfc4051.txt

[RFC 2253] Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished

Names. URL: http://www.ietf.org/rfc/rfc2253.txt
4 Overview

The fundamental purpose of security logging in D-Cinema systems is to assure that access to clear-text

content, and the use of decryption keys to accomplish this, can be tracked in trusted reports from the security

system. An important corollary of this requirement is to record that the security system itself is functioning

properly. The Security Manager component of the security system is the trusted device, which collects

information as the system operates, then processes that information to compose Security Log Records and

potentially Log Reports. While communication of Log Event data between devices in a security system must

be performed securely, such communications are outside of the scope of this document. This document does

not specify any particular security system architecture, and so uses the term "Security Device" to refer to

components of the security system generically.

The general requirements for Security Log Records external to the security system are that the records be

verifiable as to the integrity of their content, verifiable as to the completeness of a report, and verifiable as to

their source. An additional requirement is that sequences of log records must support filtering of potentially

sensitive information, while maintaining sequential integrity, i.e. the filtering of an individual record must leave

verifiable evidence of the record's existence and position in the sequence. Filtering is described in

[LogRecord].

When a system external to the security system, such as a general-purpose log management system, is

instructed to retrieve records from the security system, this standard describes how those records should be

generated and represented. The [LogRecord] standard is constructed to support filtering of log records by

omitting the body part of a record. The security system may support the generation of pre-filtered log record

sequences (with selected record bodies omitted), or filtering may be performed after the log records are

retrieved.

The Security Application Requirements section of this document constrains the application of the log format

defined in the Log Record Specification for D-Cinema [LogRecord]. These constraints ensure that this format

is applied to the expression of Log Records and Reports in a manner that provides for authentication of the

log data.

It is important to note that [LogRecord] does not actually specify the Event Types, Event Subtypes,

Parameters, or scopes for the Event Classes that it denotes, but provides a framework for doing so. The

Security Event Definitions section of this document defines the “security” Event Class as called for in

[LogRecord], including all of the detail necessary to create fully defined Log Records for security.

Page 4 of 25 pages
4 © ISO 2009 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 26430-5:2009(E)
SMPTE 430-5-2008
5 Definitions
5.1 Definition of Terms

Security Log Event – Any event that has security implications or forensic value. Such an event results in the

recording of log data.

Security Log Data – Security event information that is recorded and stored within a security device, where

such an event took place or was observed.

Security Log Record – A Log Record, containing Security Log Data, describing a Security Log Event.

Security Log Report - A sequence of Log Records as specified in [LogRecord] and subject to the constraints

specified in this document.

Security Device – A generic term, which refers to a physical or logical device which contains or uses a D-

Cinema security certificate, and which performs a D-Cinema security function.

Security Entity (SE) – A logical entity that implements one or more d-cinema security-related processes.

(e.g. a media Decryptor or a forensic marker)

Secure Processing Block (SPB) – A tamper-resistant, -evident and -responsive perimeter associated with a

Digital Certificate around security-critical information. The specific characteristics of the perimeter are outside

the scope of this specification.

Image Media Block (IMB) – The combination of Image Decryptor, Audio Decryptor, Forensic Marker(s),

Security Manager and (optionally) Link Encryptor Security Entities contained within a single Secure

Processing Block.

Remote Secure Processing Block (Remote SPB) – A Secure Processing Block other than the Image Media

Block.

Security Manager (SM) – A Security Entity responsible for parsing Key Delivery Messages and generating

Log Records. It is implemented within the Image Media Block. There is a single Security Manager associated

with each auditorium within an exhibition site.

Screen Management System (SMS) – A logical entity associated with a Digital Certificate responsible for

content management and validation within an auditorium.

SPB Marriage and Divorce – SPB Marriage and Divorce consist in the creation and termination, respectively,

of a persistent, monitored connection (electrical and physical) between two Secure Processing Blocks.

Forensic Marking – Forensic Marking (FM) is the embedding of tracking information into sound and/or image

essence by the Image Media Block during playback.

SPB Shutdown and Initialization – SPB Shutdown and Initialization mean that execution of the firmware on

the SPB has been terminated or started, respectively.

Sequence Number – refers to a count of KLV encrypted triplets in a track file, counted using the method

defined in Section 7.9 “Sequence Number” of [TFE] (2006).

Main Asset – The Main Asset in a CPL shall be the Main Picture asset if present. If the Main Picture asset is

not present, the Main Asset shall be the picture related asset that references the picture elements to be

projected on the main screen. If no main screen picture related asset is present in the CPL, the Main Asset

shall be the first asset — according to the Reel assets sequence order defined in SMPTE 429-7 — that is

used in the CPL Reels.
Page 5 of 25 pages
© ISO 2009 – All rights reserved 5
---------------------- Page: 8 ----------------------
ISO 26430-5:2009(E)
SMPTE 430-5-2008
5.2 Definitions of Processes and Validation
5.2.1 Composition Playlist Validity

A Composition Playlist is valid if all of the following conditions are satisfied.

• The message digest of all assets referenced by the Composition Playlist matches the corresponding

message digest stored in the Hash element of the CPL, as defined in Section 8.2.2 of SMPTE 429-7.

• The digital signature recorded in the Signature element, including the certificates contained therein, is

valid per the provisions of [D-Cert].
5.2.2 Frame Playback Process
The Frame Playback Process consists of
• The decryption of essence according to [TFE]; followed by:

• The validation of the integrity of essence using the Check Value and MIC, as defined in [TFE];

followed by:
• The optional forensic marking of essence; and finally followed by:

• The optional encryption of essence and transmission to a downstream device (i.e. link encryption).

5.2.3 Complete CPL Playback

A complete composition playlist (CPL) playback is the playback of a composition Playlist from the first edit unit

of the first Reel to the last edit unit of the last Reel without exception, operator intervention or other

interruptions.
5.3 Security Event Class

This document defines and constrains the Security Log Event Class. Log Records of this class shall conform

to the specifications and constraints in this document. This document also definesEvent Types and Event Sub

Types for the Security Event Class. Log Records in this class shall be identified by the URI of the Security

Class Namespace Name defined in Section 5.4 appearing in the EventClass element of the Log Record

Header as defined in [LogRecord].

Note: The Security Event Class only includes events which are specifically and clearly security related. Other events that

occur in the system could be construed as security related or not, depending upon individual interpretation, and upon

whether or not they can reasonably occur in normal operation or equipment service. For example, logging a short loss of

power, or the theft of an entire system, is outside of the scope of this standard.

5.4 Security Class Namespace

This document declares fragment identifiers in an XML namespace, whose Namespace Name (URI) shall be:

"http://www.smpte-ra.org/430-5/2008/SecurityLog/"
There are no types defined in this namespace.
5.5 Namespace Prefixes

The following table defines the namespace prefixes used in the XSDL and XML examples in this document.

Please refer to the normative references in this document and in [DCMLTypes] for specific references to the

Page 6 of 25 pages
6 © ISO 2009 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 26430-5:2009(E)
SMPTE 430-5-2008

namespaces referred to in this table. Note that the prefixes themselves are not normative, and that instance

documents may assign alternative prefixes in practice.
Prefix
Namespace Reference
xs XMLSchema
ds XMLDsig
xsi XMLSchema-Instance
dcml DcmlTypes
lr LogRecord
5.6 Reference Architectures

This specification is based on the use of one of the two architectures depicted in Figure 1.

ASM Link
Playback Device Projector
SPB
SPB
MD FM LE LD
Projector
SPB
MD FM
Figure 1 – Reference Architectures. Architecture (a) consists of two distinct
Secure Processing Blocks sharing an Auditorium Security Link.
Architecture (b) consists of a single Secure Processing Block.
6 Security Application Requirements

When a security system is requested to produce log records, that system should produce the records in a

format based on the Log Record Specification for D-Cinema [LogRecord] as constrained by this document.

Security Log Reports may contain any number of records. Security Devices may also provide status

information through other means, such as real-time messaging, but such messages are not intended to be

used as records of security events for forensic purposes, and are outside of the scope of this document.

Page 7 of 25 pages
© ISO 2009 – All rights reserved 7
---------------------- Page: 10 ----------------------
ISO 26430-5:2009(E)
SMPTE 430-5-2008
6.1 Security Constraints

When Log Records are created in a security context, the following constraints and requirements shall be

applied to the structure and content of each Log Record and Log Report containing those records. These

constraints shall be applied in addition to the constraints specified in [LogRecord].

6.1.1 Log Record Header

The following constraints shall apply to the use of elements in the Log Record Header of a Security Log

Record.
6.1.1.1 Time Stamp (Secure Time)

All time stamps shall be derived from a secure time source located in the Security Device which recorded the

event. The source or reference for that time source is outside of the scope of this document. The TimeStamp

element of the Log Record Header shall be set to a value corresponding to the time that the Security Log

Event was detected.
6.1.1.2 Event Sequences

All Log Record Headers in a Security Log Report shall contain the EventSequence element. Within each

signed sequence in a Security Log Report, the value of the EventSequence element in each Log Record shall

increase strictly (i.e. shall never remain the same or decrease) throughout the sequence.

If a single Security Log Record is signed individually (not as part of a sequence), the EventSequence element

of the Log Record Header shall not be present.
6.1.1.3 Device Source Identifiers

The DeviceSourceID list element in each Log Record Header shall contain the Certificate Thumbprint of the

security device that reported or recorded the Security Log Event, i.e. the device that the Event applies to.

6.1.1.4 Event Classes

A Log Report may contain events which are not classified as Security Events. If such events are included,

they shall be treated as part of the Log Record Sequence. When a logged event is a Security Event, the

content of the EventClass element of the Log Record Header shall be the Security Class Namespace Name

URI defined in Section 0 of this document.. Events which must be treated as Security Events are listed

elsewhere in this document.
6.1.1.5 Hashes

The PreviousHeaderHash element shall be required in all Log Record Headers, except on the first record in a

sequence. If the PreviousHeaderHash field is included in the first record in a sequence, its value shall be zero

expressed as a valid message digest value (i.e the message digest of the value zero). The

PreviousHeaderHash element shall be calculated according to the algorithm specified in [LogRecord].

The RecordBodyHash element shall be required in all Log Record Headers for all Security Events, whether

the Log Record is part of a sequence or not. The RecordBodyHash element shall be ca

...

INTERNATIONAL ISO
STANDARD 26430-5
First edition
2009-12-15
Digital cinema (D-cinema) operations —
Part 5:
Security log event class and constraints
Opérations du cinéma numérique (cinéma D) —
Partie 5: Classe et contraintes d'événement du journal de sécurité
Reference number
ISO 26430-5:2009(E)
ISO 2009
---------------------- Page: 1 ----------------------
ISO 26430-5:2009(E)
PDF disclaimer

PDF files may contain embedded typefaces. In accordance with Adobe's licensing policy, such files may be printed or viewed but shall

not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In

downloading a PDF file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat

accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.

Details of the software products used to create the PDF file(s) constituting this document can be found in the General Info relative to

the file(s); the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the files are suitable for

use by ISO member bodies. In the unlikely event that a problem relating to them is found, please inform the Central Secretariat at the

address given below.

This CD-ROM contains the publication ISO 26430-5:2009 in portable document format (PDF), which can be

viewed using Adobe® Acrobat® Reader, together with its electronic inserts.
Adobe and Acrobat are trademarks of Adobe Systems Incorporated.
COPYRIGHT PROTECTED DOCUMENT
© ISO 2009

All rights reserved. Unless required for installation or otherwise specified, no part of this CD-ROM may be reproduced, stored in a retrieval

system or transmitted in any form or by any means without prior permission from ISO. Requests for permission to reproduce this product

should be addressed to
ISO copyright office • Case postale 56 • CH-1211 Geneva 20 • Switzerland
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.