Similarities And Differences Between The IEEE And ANSI .

Transcription

Similarities and Differences between theIEEE and ANSI Standards for MeteringByAvygdor Moise, Ph.D.Future DOS Research and Development Inc.Written: August 17, 2012Revised March 13, 2012Contents1The metering standards suite . 32ANSI C12.18-2006 vs. IEEE Std 1701-2011 . 43ANSI C12.21-2006 vs. IEEE Std 1702-2011 . 44ANSI C12.22-2008 vs. IEEE Std 1703-2012 . 55ANSI C12.19-2008 vs. IEEE Std 1377-2012 and ANSI C12.19-2012 . 76AEIC Guidelines V2.0-2010 vs. AEIC Guidelines V2.1-2012. 107IETF RFC 6142-2011 . 128Registrar Certification Testing Requirements for IEEE Std 1377and ANSI C12.19. 129References . 12Disclaimer:Page 1 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

List of tablesTable 1 – The metering standards suite. 3Table 2 – Differences between ANSI C12.22-2008 and IEEE Std 1703-2012 . 5Table 3 – Differences between ANSI C12.19-2008 and IEEE Std 1377-2012 (ANSI C12.19-2012). 8Table 4 – Differences between AEIC Guidelines Version 2.0 and 2.1 . 10Disclaimer:Page 2 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

1 The metering standards suiteThe contemporary metering standards suite is a collection of seven core standards and specifications.The individual standards1 in the suite were published by IEEE (Institute of Electrical and ElectronicsEngineers), ANSI (American National Standards Institute), IETF (Internet Engineering Task Force), AEIC(Association of Edison Illuminating Companies) and NAEDRA (North American End Device RegistrationAuthority)2 as listed in Table 1 below.Table 1 – The metering standards suiteStandard or SpecificationANSI C12.18-2006 /IEEE Std 1701 -2011ANSI C12.21-2006 /IEEE Std 1702 -2011TitleOptical Port CommunicationProtocolTelephone Modem CommunicationANSI C12.22-2008 /IEEE Std 1703 -2012 /Draft ANSI C12.22-2012ANSI C12.19-2008 /IEEE Std 1377 -2012 /ANSI C12.19-2012AEIC Guidelines V2.0-2010 /AEIC Guidelines V2.1-2012Local Area Network/Wide AreaNetwork (LAN/WAN) NodeCommunicationUtility Industry End Device DataTablesIETF RFC 6142-2011SmartGrid/AEIC AMIInteroperability StandardGuidelines for ANSI C12.19 /IEEE 1377 / MC12.19 End DeviceCommunications and SupportingEnterprise Devices, Networks andRelated AccessoriesANSI C12.22, IEEE 1703 TransportOver IPCommentAlso implemented by ANSI C12.222008 / IEEE Std 1703 -2012.Legacy telephony protocols. Uses3deprecated DES3 for security. ANSIC12.22-2008 / IEEE Std 1703 2012 provide tunneling capabilitiesfor ANSI C12.21-2006 /IEEE Std 1702 -2011 payloads.Use IEEE Std 1703 -2012 in AMItesting and certification.Use IEEE Std 1377 -2012 or ANSIC12.19-2012 in AMI testing andcertification.Use for testing and certification ofconformance and interoperabilityof End Devices. MC12.19 is aCanadian part number reference toIEEE Std 1377 -2012.Defines communication overTCP/IP and UDP/IP. Supports IPv4and IPv6.1Traditionally “standards” are published by SDOs (Standard Development Organizations). However, some “standards” are alsopublished by SSOs (Standards Setting Organizations), while SDOs delegate their work to ANSI ASDs (Accredited StandardsDevelopers). Examples of SDOs include ANSI, IEC. Examples of SSO include AEIC, IETF. Examples of ASD include IEEE, NEMA,and ASHRAE.2http://www.naedra.org3Triple Data Encryption Algorithm (TDEA or Triple DEA) block cipher, which applies the Data Encryption Standard (DES) cipheralgorithm three times to each data block.Disclaimer:Page 3 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

Standard or SpecificationNAEDRA Standard TDLTesting-2012TitleRegistrar Certification TestingRequirements for IEEE 1377/ANSIC12.19/MC12.19 TDLCommentDefines requirements for testing asubmission End Device data model.2 ANSI C12.18-2006 vs. IEEE Std 1701-2011The two standards are technically identical.Recommendation: Use IEEE Std 1701-2011 (for optical port use by non-networking applications).Recommendation: Use IEEE Std 1703-2012 (for optical port use by networking AMI applications).These standards define the point-to-point ANSI Type 2 optical communication interface between anANSI C12.19-2008 / IEEE Std 1377-2012 (or ANSI C12.19-2012) End Device (e.g. meter) and a reader (e.g.hand held device). This local interface is not qualified (from a security standpoint) for network use.ANSI C12.22-2008 / IEEE Std 1703-2012 provide interface definitions that are compatible (hardware- andprotocol-wise) with ANSI C12.18-2006 / IEEE Std 17014.3ANSI C12.21-2006 vs. IEEE Std 1702-2011The two standards are technically identical.Recommendation: Use IEEE Std 1702-2011 (for telephony use by non-networking applications).Recommendation: Use IEEE Std 1703-2012 (for telephony port use by networking applications).These standards define the telephone / MODEM communication interface between anANSI C12.19-2008 / IEEE Std 1377-2012 (or ANSI C12.19-2012) End Device (e.g. meter) and a head-endsystem. This interface does not support and it is not qualified (from a security standpoint) for networkuse. Some vendors use this interface “under the glass” to bridge between ANSI C12.22-2008 / IEEE Std1703-2012 and legacy meters that implement ANSI C12.19-1997 / IEEE Std 1377-1998 and ANSI C12.211999.ANSI C12.22-2008 / IEEE Std 1703-2012 provides a pass through mode definition that enablestranslation between ANSI C12.21-2006 / IEEE Std 1702-2011 and is compatible (hardware- and protocolwise) with ANSI C12.18-2006 / IEEE Std 1701-20115.4See Either ANSI C12.22-2008 / IEEE Std 1703-2012 Clause 7, “Local port communication protocol details”.Disclaimer:Page 4 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

4 ANSI C12.22-2008 vs. IEEE Std 1703-2012The two standards should be technically identical. They are nearly identical where IEEE Std 1703-2012provides editorial corrections and corrections to descriptions on testability and proper use of theprotocol. The reader is advised to review IEEE Std 1703-2012 Annex L – Listing of editorial errors anderrors of omission in ANSI C12.22-2008. Also the Forward of Draft ANSI C12.22-2012 contains the list ofdifferences cited below.Recommendation: Use IEEE Std 1703-2012 (for detailed differences refer to IEEE Std 1703-20126).Recommendation: Use ANSI C12.22-2008 in conjunction with AEIC Guidelines V2.0-2010 or AEICGuidelines V2.1-2012.ANSI C12.22-2008 was developed under the auspices of NEMA (National Electrical ManufacturersAssociation). IEEE Std 1703-2012 was supposed to be an identical technical publication of the ANSIC12.22-2008 standard, but thanks to vendor-independent testing and implementation of the protocoland thanks to the Editorial excellence of IEEE many errors were detected in the source ANSI C12.222008 published document. These are listed in Table 2 below.Table 2 – Differences between ANSI C12.22-2008 and IEEE Std 1703-2012CategoryDocument structureDocument structureDocument StructureEditorialTechnicalChange in IEEE Std 1703-2012Document style and structure wasrevised to meet IEEE publicationstyle requirements, while preservingsection numbers.Moved clause “2.2 Other” to “AnnexK, Bibliography” and adopted IEEEstyle citations and references.Added reference to the “IEEE-SAStandards Definitions Database” inclause “3.1 Definitions”Updated references whereappropriate.Corrected definitions in 5.2.4“Universal Identifiers CanonicalEncoding” (source and target wereswapped)ImpactNoneNoneNone.Impacts only interpretation ofundefined terms.None.Now all references are properlycited and they are contemporary.None.The ANSI C12.22-2008 error is soobvious that it is unlikely for it tohave been implemented as written5See Either ANSI C12.22-2008 / IEEE Std 1703-2012 Clause 5.3.4.8.2 and Annex D, mechanism name compatibility with ANSIC12.21-2006 / IEEE Std 1702-2011 Authentication Service algorithm.6See IEEE Std 1703-2012 Annex L, “Listing of editorial errors and errors of omission in ANSI C12.22-2008”.Disclaimer:Page 5 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

CategoryChange in IEEE Std 1703-2012TechnicalAdded new response error codesclause “5.3.2.2 Response Codes”;and added missing network errorresponse codes to EPSEM serviceswhere missing (e.g. identification,security, disconnect)TechnicalCorrected octet-count in clause“5.3.2.4.2 Read Service”. Now itaccounts for the pending operationsheader correctly.Corrected data documentation inclause 5.3.2.4.3, “Write Service”.TechnicalCorrected request description inclause “5.3.2.4.5 Security Service”.Passwords are usable in bothsession and session-less operations.Documented description of domainpattern in clause “5.3.2.4.10“Registration Service”.EditorialTechnicalDisclaimer:Clarified the description of clause“5.3.2.4.12 “Resolve Service”,Clause “5.3.3 EPSEM EnvelopeStructure”, clause “5.3.4.12 Use ofSub-branches of a RegisteredApTitle”, clause “A.6 C12.22 MasterImpactin ANSI C12.22-2008. Use IEEE Std1703-2012.ANSI C12.22-2008 strictlyconforming applications may belimited in their ability to reporterrors clearly. IEEE Std 1703-2012version corrected this situation. Itprimarily impacts on End Devicesother than meters (i.e. networkinfrastructure equipment such asC12.22 Relay.Impacts on meter programming andfirmware upgrades.The ANSI C12.22-2008 version iswrong. Should use Std 1703-2012corrections.Although this is a significantdifference in interpretation, the IEEEStd 1703-2012 is actually alignedwith the use of the PSEM servicesdefined by ANSI C12.18-2006 andANSI C12.21-2006. Therefore, islikely that legacy metermanufacturers actuallyimplemented the services asdefined by ANSI C12.18, ANSIC12.21 and IEEE Std 1703-2012,while claiming “conformance” toANSI C12.22-2008.Should use IEEE Std 1703-2012correction.No change in functionality. Servicedescription was accidentally deletedin ANSI C12.18-2008 and re-insertedby the editor in IEEE Std 1703-2012.None.The ANSI C12.22-2008 descriptionwas unclear. The IEEE Std 17032012 is much clearer and eliminatesambiguities.Page 6 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

CategoryEditorialTechnicalEditorial / TechnicalChange in IEEE Std 1703-2012Relay ApTitle Auto-assignment”.Inserted “C.1 Overview” into AnnexC, and renumbered all sub-clausesin C.Field sizes (number of characters) ofdomain patterns and electronicserial number patterns wereincreased to accommodate realisticsizes of patterns.Corrected the examples (sampletest vectors) and explanation on useof the EAX’ security protocol.ImpactNone.ANSI C12.22-2008 supports veryshort recognizers for domainpatterns (domain name recognizersand asset number recognizer), IEEEStd 1703-2012 is backwardcompatible with ANSI C12.22-2008,but can handle longer patterns. Itmostly impacts Master Relay (nameservers) and some NotificationHosts (e.g. enterprise applicationsservers such as head-end systems)None.There is no difference inimplementation, but IEEE Std 17032012 example test vectors are thecorrect ones to use.5 ANSI C12.19-2008 vs. IEEE Std 1377-2012 and ANSI C12.19-2012The standards are nearly technically identical. IEEE Std 1377-2012 provides editorial corrections andcorrections to descriptions on semantics (meta-data syntax) and clarifies proper use of certain tableelements of ANSI C12.19-2008. The one major difference is that both IEEE Std 1377-2012 andANSI C12.19-2012 recognize the existence of the AEIC Guidelines V2, by providing a publishable datamodel for it. It is possible to also implement a C12.19-2008 based solution that is conforming to theAEIC Guidelines V2, but that fact may not be readily apparent as is the case when usingIEEE Std 1377-2012. The reader is advised to review IEEE Std 1377-2012 Annex N – Listing of editorialerrors and errors of omission in ANSI C12.19-2008. Also the Forward of ANSI C12.19-2012 contains thelist of differences cited below. Otherwise ANSI C12.19-2012 and IEEE Std 1377-2012 are technicallyidentical.Disclaimer:Page 7 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

Recommendation: Use IEEE Std 1377-2012 or ANSI C12.19-2012 (for detailed differences refer toIEEE Std 1377-20127).Recommendation: Use ANSI C12.19-2008 in conjunction with AEIC Guidelines V2.0-2010 orAEIC Guidelines V2.1-2012.ANSI C12.19-2008 was developed under the auspices of NEMA (National Electrical ManufacturersAssociation). IEEE Std 1377-2012 was supposed to be an identical technical publication of the ANSIC12.19-2008 standard, but thanks to NAEDRA’s testing program, vendor-independent testing andimplementation of the data model and together with the Editorial excellence of IEEE’s editor manyerrors were detected in the source of ANSI C12.19-2008 and corrected in the published IEEE Std 137720128. These are listed in Table 3 below.Table 3 – Differences between ANSI C12.19-2008 and IEEE Std 1377-2012 (ANSI C12.19-2012)CategoryDocument structureDocument structureDocument StructureEditorialEditorial78Change in IEEE Std 1377-2012Document style and structure wasrevised to meet IEEE publicationstyle requirements, while preservingsection numbers.Moved clause “2.2 Other” to “AnnexM, Bibliography” and adopted IEEEstyle citations and references.Added reference to the “IEEE-SAStandards Definitions Database” inclause “3.1 Definitions”Updated references whereappropriate.Corrected use of English forconsistencyImpactNoneNoneNone.Impacts only interpretation ofundefined terms.None.Now all references are properlycited and they are contemporary.Also IEEE Std 1377-2012 includes areference to the AEIC GuidelinesV2.0.None.e.g. All references to “byte” werereplaced with “Octet”.See IEEE Std 1377-2012 Annex N, “Listing of editorial errors and errors of omission in ANSI C12.19-2008”.Also see Draft ANSI C12.19-201x.Disclaimer:Page 8 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

CategoryEditorial / TechnicalChange in IEEE Std 1377-2012Resolved all unresolved / undefinedreferenced element names.TechnicalIntroduced new model identifier(Device Class) for AEIC GuidelinesV2. This manifests itself inMODEL SELECT in clauses 6.4.4 and9.1.1 “Table 00 GeneralConfiguration Table”.Editorial / TechnicalCorrected descriptions of read andwrite services and the use ofPending Tables in clauses 8, “Tabletransportation issues”.Editorial / TechnicalRecast and updated descriptions ofGPS COORDINATE 1,COORDINATE 2 andCOORDINATE 3 in terms ofdefinitely structured STRINGs inclause 9.1.7 “Table 06 UtilityInformation Table”.Technical/EditorialCorrected number descriptors inclause 9.2.3 “Table 12 Units ofMeasure Entry Table”.Added security best practicerecommendation to note in clauses9.5.3, “Table 42 Security Table” and9.5.6 “Table 45 Key Table”.EditorialDisclaimer:ImpactNone – CommunicationFixes – Data model.Element names that weremisspelled or improperly definedwere spelled correctly and properlydefined; while maintainingcompatibility in naming with ANSIC12.19-2008.IEEE Std 1377-2012 has an explicitawareness of the AEIC GuidelinesV2, when model select is 1,otherwise it is 0 (thus matching thatof ANSI C12.19-2008).Although it is possible to implementthe AEIC Guidelines V2 based onANSI C12.19-2008, there is noexplicit standard device classassigned to it because the ANSIStandard was published before theAEIC Guidelines V2 was written.None.These corrections now documentthese services as currentlyimplemented by ANSI C12.18-2006,ANSI C12.21-2006 and IEEE Std1703-2012.None.The new standard providesdefinitive encoding instructions forGPS coordinates. The encodingrules can be used by any existingsystem that implements ANSIC12.19-2008 (or even ANSI C12.191997).None – CommunicationFixes – Data annotationsNone.Provides better guidance on securityPage 9 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

CategoryTechnicalEditorial / TechnicalChange in IEEE Std 1377-2012Introduced new hashing function forsigning event logs and metrologydata based on FIPS PUB 180-2.Added missing descriptions ofTDL/XML meta model elementssuch as clause I.2.1.15, “ object Attributes”, I.2.1.16 “ table Attributes”, I.2.1.17 “ caption , col , thead , tfoot and tbody sub-element usage of table ” etc.ImpactThe existing MD5 hashing methodhas been deprecated by NIST. BothANSI C12.19-2008 and IEEE Std1377-2012 implement MD5.However, only IEEE Std 1377-2012implements SHA-256.None – CommunicationFixes – TDL meta-data XML modelfor automated machine use. Itimpacts on Registrars.6 AEIC Guidelines V2.0-2010 vs. AEIC Guidelines V2.1-2012The two specifications are technically identical. Version 2.0 was published in 2010, and subsequently anumber of meter manufacturers requested certain changes. The changes that were made to version 2.0(that is referenced in IEEE Std 1377-2012) do not adversely impact on ANSI C12.19-2008 and onIEEE Std 1377-2012, or the corresponding communication standards.Table 4 – Differences between AEIC Guidelines Version 2.0 and ntsDisclaimer:Change in AEIC Guidelines V2.1Corrected use of English and use ofreferences-names to standard forconsistency.Updated references whereappropriate.Clause 5.1.1 “Disclosure of DataModel”. In V2.1 disclosure shouldbe “timely” and provided in amanner that “any party mayindependently read, write, programand interpret the metering datausing the C12.19 Semantics andSyntax”.Clause 5.1.6, deleted V2.0requirements for ManufacturerOperating Manual in V2.1ImpactNone.None.Improves on interoperability andoperations.Documentation.Page 10 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

Disclaimer:Change in AEIC Guidelines V2.1Clause 5.1.6.6. Strengthenedrequirements for hidden tables.Version 2.1, “Hidden Tables orProcedures shall only be accessiblewhen the device is in FactoryMode”.Re-written minimal securityinteroperability requirements,“C12.22 provides native end-to-endsecurity mechanisms within theAPDU. C12.22 provides support formultiple standards-based securitymechanisms. In order to ensureinteroperability, all devices shall beable to support native C12.22 andC12.19 security mechanisms. Whileadditional standards-basedTransport or Network Layer securityprotocols are not required, theymay be provided, or even necessary,in order to further improve security.Layered Transport or Network Layerstandards-based security protocolsshall be transparent to the C12.22application protocol”.Clause 7.2.21[14]. Addedrequirement “Provide mechanismsto ensure the integrity of loggingand audit data”.Clause 7.3, added footnotedocumenting the use of UTF-8 inmeta data and text stating that“Implementers and users shouldnote that not all systems arecapable of visually rendering theentire UTF-8 character set. Thesesystems include meter and otherdevice displays, head-end systems,meter data management systems,customer information systems,billing systems, printed customerbills, etc.”ImpactHidden tables are not allowed postmeter production.All end-devices must implement theANSI C12.22-2008 (as corrected byIEEE Std 1703-2012) securitymechanism, in addition to anyother.All devices must implement anevent logger (e.g. for use in meterupgradability and programming).None.Page 11 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

7 IETF RFC 6142-2011This RFC provides a framework for transporting ANSI C12.22/IEEE Std 1703 Advanced MeteringInfrastructure (AMI) Application Layer Messages on an IPv4 and IPv6 networks.AEIC Guidelines V2.0-2010 and AEIC Guidelines V2.1-2012 reference RFC 6142 for use on IP networks.8 Registrar Certification Testing Requirements for IEEE Std 1377andANSI C12.19NAEDRA Registrar Certification Testing Requirements for IEEE 1377/ANSI C12.19/MC12.19 TDLVersion 1.0 defines requirements for testing a submission of a TDL (Table Definition Language) / XML(Extended Markup Language) Form representation of ANSI C12.19-2008, as corrected by IEEE Std 13772012 or equivalently ANSI C12.19-2012.9 References[1][2][3][4][5][6][7][8][9][10][11]ANSI Accredited Standards Developer (ASD) Listing9, 8/17/2012.ANS X9.52-1998 Triple Data Encryption Algorithm Modes of Operation (withdrawn)FIPS PUB 46-3 Data Encryption Standard (DES), 1999 (withdrawn).AEIC Guidelines V2.0-2010, SmartGrid/AEIC AMI Interoperability Standard Guidelines for ANSIC12.19 / IEEE 1377 / MC12.19 End Device Communications and Supporting Enterprise Devices,Networks and Related AccessoriesAEIC Guidelines V2.1-2012, SmartGrid/AEIC AMI Interoperability Standard Guidelines for ANSIC12.19 / IEEE 1377 / MC12.19 End Device Communications and Supporting Enterprise Devices,Networks and Related AccessoriesANSI C12.18-2006, Protocol Specification for ANSI Type 2 Optical PortANSI C12.19-2008, Utility Industry End Device Data TablesANSI C12.19-2012, Utility Industry End Device Data TablesANSI C12.21-2006, Protocol Specification for Telephone Modem CommunicationANSI C12.22-2008, Protocol Specification for Interfacing to Data Communication NetworksIEEE Std 1377-2012, Standard for Utility Industry Metering Communication Protocol ApplicationLayer (End Device Data nts/Standards Activities/American National Standards/ANSI Accredited StandardsDevelopers/AUG12ASD.pdfDisclaimer:Page 12 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

[12] IEEE Std 1701-2011, Standard for Optical Port Communication Protocol to Complement theUtility Industry End Device Data Tables[13] IEEE Std 1702-2011, Standard for Telephone Modem Communication Protocol to Complementthe Utility Industry End Device Data Tables[14] IEEE Std 1703-2012, Standard for Local Area Network/Wide Area Network (LAN/WAN) NodeCommunication Protocol to Complement the Utility Industry End Device Data Tables[15] IETF RFC 6142-2011, ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP, A. Moise and J.Brodkin, March 2011[16] NAEDRA Registrar Certification Testing Requirements for IEEE 1377/ANSI C12.19/MC12.19 TDLVersion 1.0 – 2012.Disclaimer:Page 13 of 13Future DOS R&D Inc., its affiliates, agents and licensors assume no liability for any inaccurate, delayed or incomplete information,nor for any actions taken in reliance thereon. The information contained is given on an “as is” basis. Prior to making any purchasingor investment decision, it is recommended that you seek advice from a qualified advisor.

Standard or Specification Title Comment ANSI C12.18-2006 / IEEE Std 1701 -2011 Optical Port Communication Protocol Also implemented by ANSI C12.22-2008 / IEEE Std 1703 -2012. ANSI C12.21-2006 / IEEE Std 1702 -2011 Telephone Modem Communication Legacy telephony protocols. Uses deprecated DES33 for secu