Service Applications Area Director(s): o David Crocker: dcrocker@mordor.stanford.edu Area Summary reported by David Crocker/Silicon Graphics The Service Applications Area was formed at the Columbus IETF meeting, splitting off from Transport Services, to provide focus on the ``middleware'' range of end-system support services, including file access, time synchronization, directory lookup and canonical access and representation procedures. NFS and ONC IETF Standards Effort BOF (ONC) ONC is a suite of protocols developed by Sun Microsystems. These protocols include: o XDR for canonical data representation o RPC for remote procedure call o NFS and NFS+ for file access o LOCKD for resource access coordination o NIS and NIS+ for resource location Sun is offering these protocols to the IETF for standardization, and the Amsterdam IETF meeting included a technical presentation followed by a discussion BOF. The presentation covered the nature and state of the various protocols. The BOF discussed the protocols in greater detail and further discussed the IETF's interest in pursuing their standardization. There was clearly sufficient interest to warrant pursuing the matter further, including formation of a working group to consider immediate standardization of some of the protocols, and to perform whatever modifications are necessary to then standardize the others. Standardization will require that Sun formally assign ``change control'' ownership to the IETF. Development of the necessary paperwork will be pursued with ISOC and its counsel. Domain Name System (DNS) The DNS Working Group covers a wide range of development and maintenance activities for the Domain Name System. Rather than dividing into multiple working groups, it is currently operating with a series of 1 sub-groups. The load balancing subgroup is interested in using the DNS to spread users across multiple machines/interfaces. The security subgroup is concerned with authentication and integrity of DNS data. The big zones subgroups is attending to the question of very large ``flat'' portions of the DNS, with ``.com'' providing the major impetus. The load balancing subgroup is basically done, having to write the informational paper and let people comment on it; there are no proposed protocol changes. The security subgroup has not done much until now, but will soon start doing the cryptographic signature work that has been discussed. The big zones subgroup has done some exploration but has not reached any kind of real closure. The subgroup will keep trying, with a few more people promising to help on this. The RFC Editor has asked the DNS Working Group to review a paper on ``Service Advertisement using the DNS.'' Marshall Rose asked for advice about some technical points of using DNS wild cards. There was an updated summary of the PIP (IPng) DNS design work by Sue Thomson; this sparked a resurrection of the old debate about the usefulness of the DNS class mechanism, which debate was stopped by the chair when it started looping. There was a discussion on some timestamp-related mechanisms that have been proposed both as part of the PIP work and as part of an incremental zone transfer protocol proposed by Anant Kumar. The general feeling was that the DNS Working Group should look into this but they do not yet understand exactly what they want. The working group agreed to take on the draft ``Common DNS Errors and Suggested Fixes'' submitted by Jon Postel, et al. The chair announced the existence of several new DNS-related Internet-Drafts, and asked other members of the working group to please review them. MHS-DS (MHSDS) The MHSDS Working Group is seeking to integrate use of the X.500 directory service into Internet X.400 operation, including e-mail routing. The MHSDS Working Group decided to publish three Internet-Drafts as Proposed Standards. An additional Internet-Draft will be published as Experimental. Minor editorial changes will be made to these documents, a final call for comments will be made to the working group, and then the documents will be progressed. In addition to document review, the working group reviewed progress of its pilot project, Project Long Bud. The Internet-Draft which describes this project will be updated to reflect comments made at this IETF meeting, the project's FTP archive will be reorganized and updated, and actions were assigned to begin investigation of ways to improve the quality of Internet X.500 service related to support of X.400 routing and address mapping. Finally, the working group held a tutorial session to help some of its membership better understand the technical details of its X.400 routing and mapping algorithms. 2 Service Location Protocol (SVRLOC) Sun's NIS+ proposal was discussed, to understand what part of the solution space it covers and whether the current service location proposal will cover the needs of NIS+ clients. The working group went through what is thought to be the list of items that are remaining to complete for the proposal to begin its travels down the IETF standards track. A document ready to submit to the standards track should be completed by the next IETF meeting. Minimal OSI Upper-Layers (THINOSI) The THINOSI Working Group is specifying a subset of the OSI upper-layer infrastructure protocols, to facilitate implementation and operational efficiency. Various issues were discussed in the review of the cookbook. A point that came up more than once was how the cookbook should relate to the parallel work in the OSI regional workshops (the Common Upper-Layer Requirements Part 3: Minimal OSI Profile (CULR3)) and in X/Open (specification of use of the XTI interface for minimal OSI (XTI/mOSI)). The possibility of the cookbook having a formal statement of compliance to CULR-3 was discussed. The eventual status of the cookbook was discussed, and it was believed it should be targetted for the standards track, as the specification of the supporting protocol layers for the relevant applications. Since the charter was written (following the BOF held in Washington, DC), the coverage of the cookbook has changed to more than just ``byte-stream'' (although the amount of new text is small). Trusted Network File Systems (TNFS) TNFS did not meet in Amsterdam. The working group has submitted a draft specification to the standards process. Final details are being resolved, prior to formal IESG review. 3