Internet Architecture Board

RFC2850

IAB Minutes 1996-03-06

Home»Documents»Minutes»Minutes 1996»IAB Minutes 1996-03-06

MINUTES FOR OPEN IAB MEETING AT LOS ANGELES IETF MEETING–March 6, 1996.

The meeting opened with Brian Carpenter hailing the departing IAB members:

    Steve Crocker, the author of RFC #1;
    Lixia Zhang, now Professor Zhang, who is going to teach students;
    Christian Huitema, no longer to be imitated by Stev Knowles; and
    Phil Gross, who, as IETF chair and then IAB member, has done so much for the IETF community.

NOTES:

    Report on IAB-sponsored Workshop on Character Sets in the Internet, Chris Weider.

      The IAB sponsored a workshop Feb. 29-March 1 before this IETF meeting on character sets. Chris Weider was the chair, and presented some of the preliminary findings from the workshop. The workshop report will be available in draft form in six weeks, with an RFC to follow shortly.

      The basic framework adopted is to use MIME tagging and registration procedures.

      Recommendations from the workshop to the IAB:

      • Examine RFCs to determine how they handle character sets–obsolete/annotate where necessary.
      • Recommend to the RFC editor and Applications Area Director that they specify character handling.
      • Produce a perspective document on character set work.
      • Is 10646 is sufficient for use?
      • Point to 10646 guidelines for character set work.
      • The IRTF should consider forming a research group on character sets.

    IAB, IETF, IRTF issues, Brian Carpenter et al.

      The IAB is keen to fulfill its architectural role. Some working groups spend significant time on non-standards track issues (research or architecture). IRTF research groups do good work that is widely unknown in the community.

      Ideas that came up during IAB discussion on these topics:

      • The IAB should identify and call out cross-area architectural issues.
      • Focus IETF on working groups on standards-track milestones (of course, managed by IESG).
      • Create new research/architectural groups to remove some of the noise from WGs.
      • These research groups might be invitational, but should regularly report to the community.
      • Existing research groups should be asked to report in open meetings.
      • In general, increase exposure of IRTF (Web pages, etc.) to the community.

      Steve Crocker took an informal poll of the audience, which showed that many people felt that the IETF is getting less efficient in its operation.

      Matt Mathis: The change has been that so much is going on that an individual can no longer keep track of the entire scope.

      Jim Bound: No way to stop the growth; we need to manage it. People are beginning to realize that the Descartes method is breaking down–look at the IETF as a complex system as a whole. How do we limit research group membership?

      Bob Hinden: The worst thing is when IETF working groups start to standardize research.

      Neil McBurnett: Open area meetings are very valuable, as a way to get a big picture overview of what is going on in other areas.

      Ran Atkinson: The last time the IETF functioned pretty well was 1992. It is a good idea to move some of the more researchy problems into the IRTF.

      Christian Huitema: The IETF no longer has anyone to compete with… we are beginning to look like those we beat.

      Fred Baker: While we may not want to standardize research efforts, much of the important work in the IETF has been research efforts when we did it. There is no sharp line.

      Matt Mathis: The need to manage the politics in relationship with other international standards bodies has forced additional formality on the organization.

      Einar Stefferud: Many of the things that appear in the IETF have not had their pre-standards work done. But there is nowhere for the work to go if it is not done here. For example, the pre-standards work for payments systems is not being done. Similarly for mobile agents.

      Phill Nesser: Where would be PIER working group fit, which is not going to create any standards-track documents? Scott Bradner: This is a general issue in the Operations Area, which is being explored at the present time. A long term question, and not an easy one. We don’t have many “users” coming to the IETF.

      Jim Bound: One of the issues we will face is that once we start to separate research from engineering, as things are rejected we need to explain why. After all, people may just go and build the “research” which can become a de-facto standard outside of the IETF. For instance, the Web. Steve Crocker: Hard cases will exist along the boundary. Rather, let’s not worry about the gray areas, but at least get the large numbers right.

      Keith McCloughlin: Is it being suggested that the Operational Area should be moved out of the IETF? No, this is one of the strengths of the IETF.

      Bill Simpson: A good IAB member is one who is directly involved in engineering, research and operations, not standing up on high and handing down direction.

      Stev Knowles: As the IRTF flowers, will it be allowed to hold close meetings at IETF meetings.

      Watch for the draft IRTF charter…

    Hearing of Perkins SMI appeal re. advancement of RFC 1902, 1903 and 1904 to draft standard.

      Dave Perkins presented his appeal–see attached slides.

      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 has appealed to the IAB as follows:

        “This appeal asks the IAB to review the decision of the IESG to elevate RFCs 1902, 1903, and 1904 to DRAFT level.

        “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.

      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.

      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.

      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

      1. the interoperability requirement extends to ASN.1 compilers
      2. that ASN.1 discrepancies in the SMI definitions lead to non-interoperability
      3. that the IESG has ignored this in its decision to approve RFC 1902, 1903 and 1904 as Draft Standard

      7. Other comments received by the IAB claim that

      1. there is massive demonstrated interoperability between SNMP agents and managers using MIBs based on the incriminated ASN.1
      2. that an informal “IETF” interpretation of ASN.1 is appropriate
      3. that the SMI inconsistencies pointed out by D. Perkins have no practical importance
      4. that these issues have been extensively discussed in the SNMPv2 WG where D. Perkins was clearly in the minority.

      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

      • regardless of which interpretation of interoperability is used, in a formal sense the interoperability requirements of RFC 1602 were not documented in this case.
      • the main reason for this is that RFC 1602 does not either precisely define interoperability, nor specify who is responsible for documenting it. Our recommendations 2 and 3 above address this.
      • the technical ambiguity arises from the history of ASN.1, and our recommendation 4 above addresses this.
      • we see no advantage to the community in reversing the IESG decision to advance the documents to Draft Standard, but they must not be further advanced until recommendation 4 has been followed and until appropriate interoperability documentation has been provided to the IESG and the community.

These minutes were prepared by Abel Weinrib, AWeinrib@ibeam.intel.com. An online copy of these and other minutes are available online http://www.iab.org/documents/IABmins.


Slides – Perkins

    SNMPv2 SMI Appeal

      David T. Perkins

      35th IETF
      IAB Meeting
      6-mar-96

    What I Want to Accomplish

      In RFCs 1902, 1903, and 1904 to:
      • fix the ambiguities;
      • complete the incomplete portions;
      • eliminate the inconsistent text; and
      • improve the clarity.

    These RFCs specify

      • The SNMP MIB language.
      • The rules for updating MIB modules and “the MIB.”
      • Administrative assignments.
      • Allowed data types in the SNMP protocol for the first choice of the second field of VarBind fields.
      • Definitions of common textual conventions.

    The Appeal

      • Requests the IAB to review the action of the IESG to elevate RFCs 1902, 1903, and 1904 to DRAFT status; and
      • Requests the IAB nullify this action, since the RFCs did not meet all of the requirements for advancement to DRAFT status.

    Requirements for DRAFT

      All aspects of a specification must:
      • Be well understood.
      • Have two independent implementations (i.e., creations of working code).
      • Demonstrate interoperation of the implementations.
      • Have sufficient deployment experience.

    Summary

      I want to:
      • Follow the process rules.
      • Improve the SNMPv2 SMI documents.
      • Update my implementation and demonstrate interoperation with others.
      • See other RFCs dependent on the SMI documents move forward.
      • Move on to other issues.

    Current Status

    I believe:

    • the IAB understands the issues
    • the IAB has chosen an approach that will resolve the issues
    • the POISED WG understands the process issues
    • the POISED WG has addressed them in the latest poised draft

    Thank you for your consideration

      David T. Perkins