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