Question(s):
7/13
Meeting, date:
Study Group:
13
Working Party:
2/13
Source:
Editor of Y.2771 (ex Y.dpifr)
Title:
A.5 justification information for draft new Y.2771 (ex Y.dpifr) "Framework for deep packet inspection"
Contact:
Name
Organization
Country
Tel: +
xx
E-mail:
a@b.com
Contact:
Tel: +xx
E-mail:a@b.com
Abstract:
This TD contains the A.5 justification for draft new Y.2771 (ex Y.dpifr) "Framework for deep packet inspection" including the following normative references: ETSI TS 132 410 V11.0.0 (2010-12), IETF RFC 791 (1981), IETF RFC 2460 (1998), IETF RFC 2544 (1999), IETF RFC 3060 (2001), IETF RFC 4011 (2005), IETF RFC 5101 (2008).
1Introduction
According to ITU procedures, as described in
ITU-T Recommendation A.5
, any normative reference to documentation produced outside the ITU (other than ISO and IEC texts) needs to be evaluated by the study group or working party before a decision is made to incorporate the reference in an ITU-T Recommendation.
This TD contains the A.5 justification information for new Y.2771 (ex Y.dpifr) "Framework for deep packet inspection".
2Referred documents and respective justifications
- ETSI TS 132 410 V11.0.0 (2010-12): Digital cellular telecommunications system (Phase 2+);Universal Mobile Telecommunications System (UMTS);LTE; Telecommunication management; Key Performance Indicators (KPI) for UMTS and GSM (3GPP TS 32.410 version 11.0.0 Release 11.
-
Published standard
-
This Recommendation classify the DPI performance metircs into KPI and non-KPI. This recommendation use the definition of KPI from [ETSI TS 132.410], see in clause 8.2
-
Complete A.5 justification information can be found in
Annex 1
.
- IETF RFC 791 (1981): Internet Protocol, September 1981
-
Approved legacy document.
-
The DPI functional model is based on packet forwarding function (PFF). The PFF may be e.g. a switching function in case of MPLS label switching routers (LSR) or Ethernet switches or bridges , or a forwarding/routing function in case of IPv4 [IETF RFC 791] and IPv6 [IETF RFC 2460] routers. See clause 7.
-
Complete A.5 justification information can be found in
Annex 2
.
- IETF RFC 2460 (1998): Internet Protocol, Version 6 (IPv6) Specification
-
Approved as standards track document.
-
The DPI functional model is based on packet forwarding function (PFF). The PFF may be e.g. a switching function in case of MPLS label switching routers (LSR) or Ethernet switches or bridges , or a forwarding/routing function in case of IPv4 [IETF RFC 791] and IPv6 [IETF RFC 2460] routers. See clause 7.
-
Complete A.5 justification information can be found in
Annex 3
.
- IETF RFC 2544 (1999): Benchmarking Methodology for Network Interconnect Devices
-
Approved IETF document
-
The DPI metric “node-internal transfer delay” is a KPI.the packet size Sp used to measure this KPI could be related to the L2 frame size value given by the [IETF RFC 2544]. See clause 8.
-
Complete A.5 justification information can be found in
Annex 4
.
- IETF RFC 3060 (2001): Policy Core Information Model - Version 1 Specification, February 2002.
-
The referred RFCs were approved by IESG (Internet Engineering Steering Group).
-
The DPI policy rule information modeling may serve [IETF RFC 3060] as baseline.See cluase 7.
-
Complete A.5 justification information can be found in
Annex 5
.
- IETF RFC 4011 (2005): Policy Based Management MIB
-
The referred RFC was approved by IESG (Internet Engineering Steering Group).
-
DPI policy rule data modeling may serve [IETF RFC 4011] as baseline. See clause 7.
-
Complete A.5 justification information can be found in
Annex 6
.
- IETF RFC 5101 (2008): Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
-
IETF RFC 5101(2008) is a PROPOSED STANDARD
-
The IETF IPFIX flow metering function is defined in [IETF RFC 5101].The IETF IPFIX flow process may be abstracted and described as DPI policy rule, therefore directly mapped on a DPI-FE. See clause 7.1.9.
-
Complete A.5 justification information can be found in
Annex 7
.
Annex 1
A.5 justification information for the reference to ETSI TS 132 410 V11.0.0 (2010-12)
1
Clear description of the referenced document:
ETSI TS 132 410 V11.0.0 (2010-12): Digital cellular telecommunications system (Phase 2+);Universal Mobile Telecommunications System (UMTS);LTE; Telecommunication management; Key Performance Indicators (KPI) for UMTS and GSM (3GPP TS 32.410 version 11.0.0 Release 11.
2
Status of approval:
Published standard
3
Justification for the specific reference:
This Recommendation classify the DPI performance metircs into KPI and non-KPI. This recommendation use the definition of KPI from [ETSI TS 132.410], see in clause 8.2
4
Current information, if any, about IPR issues:
ETSI IPR information is available at http://www.etsi.org/
5
Other useful information describing the "Quality" of the document:
None.
6
The degree of stability or maturity of the document:
This is an approved version of an evolving standard and has been published by ETSI (and also by 3GPP).
7
Relationship with other existing or emerging documents:
None.
8
Any explicit references within that referenced document should also be listed:
[1] 3GPP TS 32.404: "Telecommunication management; Performance Management (PM);Performance measurements - Definitions and template".[2] 3GPP TS 32.405: "Telecommunication management; Performance Management (PM);Performance measurements Universal Terrestrial Radio Access Network (UTRAN) ".[3] 3GPP TS 32.406: "Telecommunication management; Performance Management (PM);Performance measurements Core Network (CN) Packet Switched (PS) domain".[4] 3GPP TS 32.407: "Telecommunication management; Performance Management (PM);Performance measurements Core Network (CN) Circuit Switched (CS) domain".[5] 3GPP TS 32.408: "Telecommunication management; Performance Management (PM);Performance measurements Teleservice".[6] 3GPP TS 32.409: "Telecommunication management; Performance Management (PM);Performance measurements IP Multimedia Subsystem (IMS) ".[7] 3GPP TS 52.402: "Telecommunication management; Performance Management (PM);Performance measurements - GSM".[8] 3GPP TR 32.814: "Telecommunication management; UTRAN and GERAN Key PerformanceIndicators (KPI)".[9] ITU-T Recommendation E.800: "Terms and definitions related to quality of service and networkperformance including dependability".[10] TMF GB917: "SLA management handbook, release 2.5", July 2005.[11] TMF GB923: "Wireless service measurements handbook", version 3.0, March 2004.[12] 3GPP TS 25.331: "Radio Resource Control (RRC); Protocol specification".
9
Qualification of ETSI:
ETSI is recognized under the provisions of ITU-T Recommendations A.5 and A.6. Qualifying information is on file at TSB.
10
Other (for any supplementary information):
None
Annex 2
A.5 justification information for the reference to IETF RFC 791 (1981)
1
Clear description of the referenced document:
IETF RFC 791 (1981): Internet Protocol, September 1981
2
Status of approval:
Approved legacy document.
3
Justification for the specific reference:
The DPI functional model is based on packet forwarding function (PFF). The PFF may be e.g. a switching function in case of MPLS label switching routers (LSR) or Ethernet switches or bridges , or a forwarding/routing function in case of IPv4 [IETF RFC 791] and IPv6 [IETF RFC 2460] routers. See clause 7.
4
Current information, if any, about IPR issues:
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=791
5
Other useful information describing the "Quality" of the document:
This RFC has been approved in September 1981.
6
The degree of stability or maturity of the document:
This reference is a standards-track document and is currently in the "Proposed Standard" state. Current standards status of this document can be found at ftp://ftp.isi.edu/in-notes/std/std1.txt. Errata Exist. Updated by RFC 1349, RFC 6864, RFC 2474.
7
Relationship with other existing or emerging documents:
RFC 791 is a fundamental component of the basic suite of internet protocols and standards. Updated by RFC 2474, RFC 6864, RFC 1349 , Errata exhist. Obsoletes RFC 760
8
Any explicit references within that referenced document should also be listed:
[1] Cerf, V., "The Catenet Model for Internetworking", IEN 48, July 1978.[2] Bolt Beranek and Newman, "Specification for the Interconnection of a Host and an IMP," BBN Technical Report 1822, Revised May 1978.[3] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification," RFC 792, September 1981.[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing," COMPCON, IEEE Computer Society, Fall 1978.[5] Postel, J., "Address Mappings," RFC 796, September 1981.[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols," Computer Networks, v. 3, n. 1, February 1979.[7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and Newman, August 1979.[8] Postel, J., "Service Mappings," RFC 795, September 1981.[9] Postel, J., "Assigned Numbers," RFC 790, September 1981.
9
Qualification of ISOC/IETF:
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
10
Other (for any supplementary information):
If the Study Group decides to make the reference to the RFC, the reference should always be made by RFC number (and not by other designations such as STD, BCP, etc.). References should not be made to documents referred to as "Internet Drafts" or RFCs categorized as "Historic".
Annex 3
A.5 justification information for the reference to IETF RFC 2460 (1998)
1
Clear description of the referenced document:
IETF RFC 2460 (1998): Internet Protocol, Version 6 (IPv6) Specification
2
Status of approval:
Approved as standards track document.
3
Justification for the specific reference:
The DPI functional model is based on packet forwarding function (PFF). The PFF may be e.g. a switching function in case of MPLS label switching routers (LSR) or Ethernet switches or bridges , or a forwarding/routing function in case of IPv4 [IETF RFC 791] and IPv6 [IETF RFC 2460] routers. See clause 7.
4
Current information, if any, about IPR issues:
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=2460
5
Other useful information describing the "Quality" of the document:
The status of all the referred RFCs, is "Proposed Standard".
6
The degree of stability or maturity of the document:
The status of all the referred RFCs, is "Proposed Standard".
7
Relationship with other existing or emerging documents:
References within the referenced RFC are listed under item (8).
8
Any explicit references within that referenced document should also be listed:
[1] IETF RFC 2401 (1998), Security Architecture for the Internet Protocol [2] IETF RFC 2402 (1998), IP Authentication Header[3] IETF RFC 2406 (1998), IP Encapsulating Security Protocol (ESP) [4] IETF RFC 2463(1998), ICMP for the Internet Protocol Version 6 (IPv6) [5] IETF RFC 2373 (1998), IP Version 6 Addressing Architecture [6] IETF RFC 1981 (1996), Path MTU Discovery for IP version 6[7] IETF STD 5, RFC 791 (1981), Internet Protocol [8] IETF STD 2, RFC 1700 (1994), Assigned Numbers[9] IETF STD 51, RFC 1661 (1994), The Point-to-Point Protocol (PPP)
9
Qualification of ISOC/IETF:
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
10
Other (for any supplementary information):
None
Annex 4
A.5 justification information for the reference to IETF RFC 2544 (1999)
1
Clear description of the referenced document:
IETF RFC 2544 (1999): Benchmarking Methodology for Network Interconnect Devices
2
Status of approval:
Approved IETF document
3
Justification for the specific reference:
The DPI metric “node-internal transfer delay” is a KPI.the packet size Sp used to measure this KPI could be related to the L2 frame size value given by the [IETF RFC 2544]. See clause 8.
4
Current information, if any, about IPR issues:
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=2544
5
Other useful information describing the "Quality" of the document:
Widely implemented and deployed.
6
The degree of stability or maturity of the document:
Stable
7
Relationship with other existing or emerging documents:
Obsoletes RFC 1944
8
Any explicit references within that referenced document should also be listed:
RFC 1242
9
Qualification of ISOC/IETF:
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
10
Other (for any supplementary information):
None
Annex 5
A.5 justification information for the reference to IETF RFC 3060 (2001)
1
Clear description of the referenced document:
IETF RFC 3060 (2001): Policy Core Information Model - Version 1 Specification, February 2002.
2
Status of approval:
The referred RFCs were approved by IESG (Internet Engineering Steering Group).
3
Justification for the specific reference:
The DPI policy rule information modeling may serve [IETF RFC 3060] as baseline.See cluase 7.
4
Current information, if any, about IPR issues:
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3060
5
Other useful information describing the "Quality" of the document:
The status of all the referred RFCs is "Proposed Standard".
6
The degree of stability or maturity of the document:
The status of all the referred RFCs is "Proposed Standard".
7
Relationship with other existing or emerging documents:
References within the referenced RFCs are listed under item (8).
8
Any explicit references within that referenced document should also be listed:
[1] Distributed Management Task Force, Inc., "DMTF Technologies: CIM Standards CIM Schema: Version 2.4", available via links on the following DMTF web page:http://www.dmtf.org/spec/cim_schema_v24.html.[2] Distributed Management Task Force, Inc., "Common Information Model (CIM) Specification, version 2.2, June 1999. This document is available on the following DMTF web page: http://www.dmtf.org/spec/cims.html.[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[4] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.[5] J. Strassner and S. Judd, "Directory-Enabled Networks", version 3.0c5 (August 1998). A PDF file is available at http://www.murchiso.com/den/#denspec.[6] J. Strassner, policy architecture BOF presentation, 42nd IETF Meeting, Chicago, Illinois, October, 1998. Minutes of this BOF are available at the following location: http://www.ietf.org/proceedings/98aug/index.html.[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.[8] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations", RFC 2591, May 1999.[9] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.[10] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.[11] Strassner, J., and E. Ellesson, B. Moore, R. Moats, "Policy Core LDAP Schema", Work in Progress.[12] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
9
Qualification of ISOC/IETF:
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
10
Other (for any supplementary information):
The referred IETF RFCs are available on the web.
[1] IETF RFC 3060 - Policy Core Information Model - Version 1 Specification: available at "http://www.ietf.org/rfc/rfc3060.txt"
Annex 6
A.5 justification information for the reference to IETF RFC 4011 (2005)
1
Clear description of the referenced document:
IETF RFC 4011 (2005): Policy Based Management MIB
2
Status of approval:
The referred RFC was approved by IESG (Internet Engineering Steering Group).
3
Justification for the specific reference:
DPI policy rule data modeling may serve [IETF RFC 4011] as baseline. See clause 7.
4
Current information, if any, about IPR issues:
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=4016
5
Other useful information describing the "Quality" of the document:
Standards Track
6
The degree of stability or maturity of the document:
Standards Track
7
Relationship with other existing or emerging documents:
References within the referenced RFCs are listed under item (8).
8
Any explicit references within that referenced document should also be listed:
Normative References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [4] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [5] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [6] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [7] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [8] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet- standard Network Management Framework", BCP 74, RFC 3584, August 2003. [9] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [10] International Standards Organization, "Information Technology - Programming Languages - C++", ISO/IEC 14882-1998 [11] Daniele, M. and J. Schoenwaelder, "Textual Conventions for Transport Addresses", RFC 3419, December 2002. [12] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations", RFC 3231, January 2002. [13] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [15] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. Informative References [16] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [17] ECMA, "ECMAScript Language Specification", ECMA-262, December 1999 [18] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [19] MacFaden, M., Partain, D., Saperia, J., and W. Tackabury, "Configuring Networks and Devices with Simple Network Management Protocol (SNMP)", RFC 3512, April 2003.
9
Qualification of ISOC/IETF:
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
10
Other (for any supplementary information):
None
Annex 7
A.5 justification information for the reference to IETF RFC 5101 (2008)
1
Clear description of the referenced document:
IETF RFC 5101 (2008): Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
2
Status of approval:
IETF RFC 5101(2008) is a PROPOSED STANDARD
3
Justification for the specific reference:
The IETF IPFIX flow metering function is defined in [IETF RFC 5101].The IETF IPFIX flow process may be abstracted and described as DPI policy rule, therefore directly mapped on a DPI-FE. See clause 7.1.9.
4
Current information, if any, about IPR issues:
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=5101
5
Other useful information describing the "Quality" of the document:
The intended status of the referred draft, is "Proposed Standard".
6
The degree of stability or maturity of the document:
The intended status of the referred draft, is "Proposed Standard".
7
Relationship with other existing or emerging documents:
References within the referenced draft are listed under item (8).
8
Any explicit references within that referenced document should also be listed:
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.[RFC5102] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
9
Qualification of ISOC/IETF:
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
10
Other (for any supplementary information):
Reference should always be made by RFC number (and not by other designations such as STD, BCP, etc.). References should not be made to documents referred to as "Internet Drafts" or to IETF RFCs categorized as Historic or Experimental. Normative references must only be made to IETF RFCs that are Standards Track or to Informational RFCs that have IETF consensus.
_________________
-
PAGE
1
-