< draft-dusseault-impl-reports-03.txt   draft-dusseault-impl-reports-04.txt >
Network Working Group L. Dusseault Network Working Group L. Dusseault
Internet-Draft Messaging Architects Internet-Draft Messaging Architects
Updates: 2026 (if approved) R. Sparks Updates: 2026 (if approved) R. Sparks
Intended status: BCP Tekelec Intended status: BCP Tekelec
Expires: December 20, 2009 June 18, 2009 Expires: January 3, 2010 July 2, 2009
Guidance on Interoperation and Implementation Reports Guidance on Interoperation and Implementation Reports for Advancement to
draft-dusseault-impl-reports-03 Draft Standard
draft-dusseault-impl-reports-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 20, 2009. This Internet-Draft will expire on January 3, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 24 skipping to change at page 2, line 25
4. Feature Coverage . . . . . . . . . . . . . . . . . . . . . . . 7 4. Feature Coverage . . . . . . . . . . . . . . . . . . . . . . . 7
5. Special Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Special Cases . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Deployed Protocols . . . . . . . . . . . . . . . . . . . . 8 5.1. Deployed Protocols . . . . . . . . . . . . . . . . . . . . 8
5.2. Undeployed Protocols . . . . . . . . . . . . . . . . . . . 9 5.2. Undeployed Protocols . . . . . . . . . . . . . . . . . . . 9
5.3. Schemas, languages and formats . . . . . . . . . . . . . . 9 5.3. Schemas, languages and formats . . . . . . . . . . . . . . 9
5.4. Multiple Contributors, Multiple Implementation Reports . . 9 5.4. Multiple Contributors, Multiple Implementation Reports . . 9
5.5. Test Suites . . . . . . . . . . . . . . . . . . . . . . . 10 5.5. Test Suites . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Optional Features, extensibility features . . . . . . . . 10 5.6. Optional Features, extensibility features . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Minimal Implementation Report . . . . . . . . . . . . . . 11 6.1. Minimal Implementation Report . . . . . . . . . . . . . . 11
6.2. Covering Exceptions . . . . . . . . . . . . . . . . . . . 11 6.2. Covering Exceptions . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Draft Standard level, and requirements for standards to meet it, The Draft Standard level, and requirements for standards to meet it,
skipping to change at page 5, line 15 skipping to change at page 5, line 15
chosen or self-selected. See also the note on implementation chosen or self-selected. See also the note on implementation
independence below. independence below.
o The report author MAY choose an appropriate level of detail to o The report author MAY choose an appropriate level of detail to
document feature interoperability, rather than document each document feature interoperability, rather than document each
individual feature. See note on granularity of features below. individual feature. See note on granularity of features below.
o A contributor other than a WG chair MAY submit an implementation o A contributor other than a WG chair MAY submit an implementation
report to an AD. report to an AD.
o Optional features that are not implemented, but are important and
do not harm interoperability, MAY, exceptionally and with approval
of the IESG, be left in a protocol at Draft Standard. See
Section 5.6 for documentation requirements and an example of where
this is needed.
Note: Independence of implementations is mentioned in the RFC2026 Note: Independence of implementations is mentioned in the RFC2026
requirements for Draft Standard status. Independent requirements for Draft Standard status. Independent
implementations should be written by different people at different implementations should be written by different people at different
organizations using different code and protocol libraries. If organizations using different code and protocol libraries. If
it's necessary to relax this definition, it can be relaxed as long it's necessary to relax this definition, it can be relaxed as long
as there is evidence to show that success is due more to the as there is evidence to show that success is due more to the
quality of the protocol than to out-of-band understandings or quality of the protocol than to out-of-band understandings or
common code. If there are only two implementations of an common code. If there are only two implementations of an
undeployed protocol, the report SHOULD identify the undeployed protocol, the report SHOULD identify the
implementations and their "genealogy" (which libraries were used implementations and their "genealogy" (which libraries were used
skipping to change at page 5, line 44 skipping to change at page 5, line 50
implementation report need not be as detailed. A report need not implementation report need not be as detailed. A report need not
list every "MAY", "SHOULD" and "MUST" in a complete matrix across list every "MAY", "SHOULD" and "MUST" in a complete matrix across
implementations. A more effective approach might be to implementations. A more effective approach might be to
characterize the interoperability quality and testing approach, characterize the interoperability quality and testing approach,
then call out any known problems in either testing or then call out any known problems in either testing or
interoperability. interoperability.
3. Format 3. Format
The format of implementation and interoperability reports MUST be The format of implementation and interoperability reports MUST be
ASCII text with line-breaks for readability. It is acceptable, but ASCII text with line-breaks for readability. As with Internet-
not necessary, for a report to be formatted as an Internet Draft. Drafts, no 8-bit characters are currently allowed. It is acceptable,
but not necessary, for a report to be formatted as an Internet Draft.
Here is a simple outline that an implementation report MAY follow in Here is a simple outline that an implementation report MAY follow in
part or in full: part or in full:
Title: Titles of implementation reports are strongly RECOMMENDED to Title: Titles of implementation reports are strongly RECOMMENDED to
contain one or more RFC number for consistent lookup in a simple contain one or more RFC number for consistent lookup in a simple
archive. In addition, the name or a common mnemonic of the archive. In addition, the name or a common mnemonic of the
standard should be in the title. An example might look like standard should be in the title. An example might look like
"Implementation Report for the Example Name of Some Protocol "Implementation Report for the Example Name of Some Protocol
(ENSP) RFC-XXXX". (ENSP) RFC-XXXX".
Author Identify the author of the report. Author: Identify the author of the report.
Summary: Attest that the standard meets the requirements for Draft Summary: Attest that the standard meets the requirements for Draft
Standard and name who is attesting it. Describe how many Standard and name who is attesting it. Describe how many
implementations were tested or surveyed. Quickly characterize the implementations were tested or surveyed. Quickly characterize the
deployment level and where the standard can be found in deployment level and where the standard can be found in
deployment. Call out, and if possible, briefly describe any deployment. Call out, and if possible, briefly describe any
notably difficult or poorly interoperable features and explain why notably difficult or poorly interoperable features and explain why
these still meet the requirement. Assert any derivative these still meet the requirement. Assert any derivative
conclusions: if a high-level system is tested and shown to work, conclusions: if a high-level system is tested and shown to work,
then we may conclude that the normative requirements of that then we may conclude that the normative requirements of that
skipping to change at page 9, line 36 skipping to change at page 9, line 36
5.3. Schemas, languages and formats 5.3. Schemas, languages and formats
Standards that are not on-the-wire protocols may be special cases for Standards that are not on-the-wire protocols may be special cases for
implementation reports. The IESG SHOULD use judgement in what kind implementation reports. The IESG SHOULD use judgement in what kind
of implementation information is acceptable for these kinds of of implementation information is acceptable for these kinds of
standards. ABNF (RFC 4234) is an example of a language for which an standards. ABNF (RFC 4234) is an example of a language for which an
implementation report was filed: it is interoperable in that implementation report was filed: it is interoperable in that
protocols are specified using ABNF and these protocols can be protocols are specified using ABNF and these protocols can be
successfully implemented and syntax verified. Implementations of successfully implemented and syntax verified. Implementations of
ABNF include the RFCs that use it as well as ABNF checking software. ABNF include the RFCs that use it as well as ABNF checking software.
MIBs are sometimes documented in implementation reports and examples
of that can be found in the archive of implementation reports.
The interoperability reporting requirements for some classes of
documents may be discussed in separate documents. See
[I-D.bradner-metricstest] for example.
5.4. Multiple Contributors, Multiple Implementation Reports 5.4. Multiple Contributors, Multiple Implementation Reports
If it's easiest to divide up the work of implementation reports by If it's easiest to divide up the work of implementation reports by
implementation, the result -- multiple implementation reports -- MAY implementation, the result -- multiple implementation reports -- MAY
be submitted to the sponsoring Area Director one-by-one. Each report be submitted to the sponsoring Area Director one-by-one. Each report
might cover one implementation, including: might cover one implementation, including:
identification of the implementation, identification of the implementation,
an affirmation that the implementation works in testing (or an affirmation that the implementation works in testing (or
better, in deployment) , better, in deployment) ,
whether any features are known to interoperate poorly with other whether any features are known to interoperate poorly with other
implementations, implementations,
which optional or required features are not implemented (note that which optional or required features are not implemented (note that
there are no protocol police to punish this disclosure, we should there are no protocol police to punish this disclosure, we should
instead thank implementors who point out unimplemented or instead thank implementors who point out unimplemented or
unimplementable features especially if they can explain why), unimplementable features especially if they can explain why),
who is submitting this report for this implementation. who is submitting this report for this implementation.
These SHOULD be collated into one document for archiving under one These SHOULD be collated into one document for archiving under one
title, but can be concatenated trivially even if the result has title, but can be concatenated trivially even if the result has
several summary sections or introductions. several summary sections or introductions.
skipping to change at page 10, line 49 skipping to change at page 11, line 7
5.6. Optional Features, extensibility features 5.6. Optional Features, extensibility features
Optional features need not be shown to be implemented everywhere. Optional features need not be shown to be implemented everywhere.
However, they do need to be implemented somewhere, and more than one However, they do need to be implemented somewhere, and more than one
independent implementation is required. If an optional feature does independent implementation is required. If an optional feature does
not meet this requirement, the implementation report must say so and not meet this requirement, the implementation report must say so and
explain why the feature must be kept anyway versus being evidence of explain why the feature must be kept anyway versus being evidence of
a poor-quality standard. a poor-quality standard.
Extensibility features are particularly likely to need this kind of Extensibility points and versioning features are particularly likely
treatment. When a protocol version 1 is released, the protocol to need this kind of treatment. When a protocol version 1 is
version field itself is likely to be unused. Before any other released, the protocol version field itself is likely to be unused.
versions exist, it can't really be demonstrated that this particular Before any other versions exist, it can't really be demonstrated that
field or option is implemented. this particular field or option is implemented.
6. Examples 6. Examples
Some good, extremely brief examples of implementation reports can be Some good, extremely brief examples of implementation reports can be
found in the archives. found in the archives.
http://www.ietf.org/IESG/Implementations/ http://www.ietf.org/IESG/Implementations/
PPP-LCP-EXT-implementation PPP-LCP-EXT-implementation
http://www.ietf.org/IESG/Implementations/OTP-Draft-implementation http://www.ietf.org/IESG/Implementations/OTP-Draft-implementation
skipping to change at page 12, line 38 skipping to change at page 12, line 44
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[I-D.bradner-metricstest]
Bradner, S. and V. Paxson, "Advancement of metrics
specifications on the IETF Standards Track",
draft-bradner-metricstest-03 (work in progress),
August 2007.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005. Syndication Format", RFC 4287, December 2005.
Authors' Addresses Authors' Addresses
Lisa Dusseault Lisa Dusseault
Messaging Architects Messaging Architects
Email: lisa.dusseault@messagingarchitects.com Email: lisa.dusseault@gmail.com
Robert Sparks Robert Sparks
Tekelec Tekelec
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
Dallas, Texas 75254-4203 Dallas, Texas 75254-4203
USA USA
Email: RjS@nostrum.com Email: RjS@nostrum.com
 End of changes. 13 change blocks. 
15 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/