Extract from Minutes of the March 1996 IAB Meeting
Dierdre Kostick, Network Management AD: The SMI language is adequate for writing MIB modules. It is good that Dave pays close attention to our language specification, but it would be a shame to hold up our work on MIBs for a process issue. The issues can be fixed by normal document revisions.
Ed Hanson: The language is broken with syntax errors. It needs to be fixed.
Jim Bound: It sounds as though an implementor is telling us that the specification is broken.
Bill Simpson: Why were the documents published when an appeal was in progress?
Fred Baker: The basis of the original complaint was that there are interoperability problems--just like in C. There are several compilers that do interoperate. We should say: yes, improvements need to be made, but keep them in perspective.
Keith McCloughlin (document editor): Each version of the documents are better, due to Dave Perkin's and other's input.
Stev Knowles: As a former area director, he heard that the network management AD did not want the process to get in the way of her documents. Could she comment.
Dierdre Kostick: We are becoming a board of lawyers focusing on process, rather than on engineering. Let's focus on engineering. Does the severity of the problems with the documents warrant reducing the status of the documents?
Scott Bradner: Yes, we are needing to focus on process, so that the standards setting process appears fair. We can not dismiss the rules that we have made for ourselves.
Dave Perkins outlined the requirements for various levels of documents on the standards track. There are parts of the SMI document set that have been little discussed and implemented, especially the conformance test document.
The IAB huddled, and announced its conclusion:
IAB CONCLUSIONS ON SMI APPEAL BY DAVID PERKINS
David Perkins <dperkins@scruznet.com> has appealed to the IAB as follows:
"This appeal asks that these specifications have their status level changed back to PROPOSED until ALL THE REQUIREMENTS as specified in RFC 1602 (and clarified in the poised WG draft) are met."
1. The IAB decided to accept this appeal although a close reading of RFC 1602 shows that there is no provision for appealing IESG decisions.
The IAB notes that the RFCs were published despite an appeal being under way, there being no provision for delaying publication in RFC 1602. The IAB believes this was correct, in the interests of timeliness.RECOMMENDATION 1: The IAB recommends that the replacement for RFC 1602 should clarify and broaden the possible grounds for appeal, as already covered in the relevant poised'95 WG draft.
2. The appeal was notified to the IAB on January 10, 1996 and to the IETF list on January 23. On January 30 the IAB requested email submissions by February 10, and received some 25 messages. The appeal was discussed in the IAB teleconference on February 13, in the IAB's face-to-face meeting at the LA IETF, and in the Open IAB meeting at the LA IETF where final verbal submissions were made by David Perkins, Dierdre Kostick and others.
3. One issue in the appeal is whether the interoperability requirement of the IETF standards process is limited to interoperability of different implementations "over the wire" or whether its scope is wider. The IAB has concluded that the general understanding of "interoperability" in the IETF is limited to "over the wire" but this may be too narrow in some cases, such as the present one.
RECOMMENDATION 2: The IAB recommends that the replacement for RFC 1602 should clarify the meaning of "interoperable implementations", as already covered in the relevant poised'95 WG draft.
4. A related issue is that RFC 1602 does not make clear who is responsible for documenting demonstrations of interoperability, and who is reponsible for making this documentation available to the community.
RECOMMENDATION 3: The IAB recommends that the relevant WG chair should be responsible for documenting interoperability demonstrations, and for providing this information to the IESG via the Area Director. The IETF Secretariat should be responsible for making this material available to the community. The replacement for RFC 1602 should specify these responsibilities.
5. A technical issue in the appeal is whether the SNMP usage of ASN.1 is viewed as usage of an SNMP "dialect" of ASN.1 or strict formal usage of one of the formal standard versions of ASN.1. In the former case, conformance requirements can be treated more loosely than in the latter. The IAB has concluded that the general understanding in the IETF is that SNMP uses a dialect of ASN.1-1988 and does not conform strictly to either ASN.1-1988 or ASN.1-1994. However the dialect of ASN.1-1988 used is not properly documented.
RECOMMENDATION 4: The IAB recommends that the NM AD charters a short-lived WG (or a BOF, if that is sufficient) to document this ASN.1 dialect.
6. D. Perkins appears to claim that
7. Other comments received by the IAB claim that
8. The IAB notes that in its "protocol action" referring to the SMI documents, the IESG noted that some editorial changes are needed prior to full Standard status. However we also note that the messages from the WG Chair to the NM AD, that asked for the documents to be progressed, did not specifically address the interoperability issue. It seems to have been assumed that since the interoperability of SNMPv2 managers and agents was common knowledge, that was sufficient. Indeed, as noted above, RFC 1602 does not specify who should be responsible for documenting interoperability.
9. The IAB concludes that
35th IETF
IAB Meeting
6-mar-96