draft-ietf-nfsv4-acl-mapping-00.txt   draft-ietf-nfsv4-acl-mapping-01.txt 
Network Working Group Marius Aamodt Eriksen Network Working Group Marius Aamodt Eriksen
Document: draft-ietf-nfsv4-acl-mapping-00.txt Document: draft-ietf-nfsv4-acl-mapping-01.txt
Mapping Between NFSv4 and Posix Draft ACLs Mapping Between NFSv4 and Posix Draft ACLs
Status of this Memo SSttaattuuss ooff tthhiiss MMeemmoo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 mate-
material or to cite them other than as "work in progress." rial 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.
"Copyright (C) The Internet Society (2003). All Rights Reserved." "Copyright (C) The Internet Society (2002-2004). All Rights
Reserved."
Abstract
The NFS (Network File System) version 4[rfc3530] (NFSv4) specifies a AAbbssttrraacctt
flavor of Access Control Lists (ACLs) that apply to file system
objects. ACLs specify an access level for a number of entities. The
NFSv4 ACLs model resembles that of Windows NT. A POSIX
draft[posixacl] proposes another, more restrictive ACL model. Many
systems implement this proposed standard. Differing in syntax,
semantics and extensiveness, it is only feasible to create a correct
representation for POSIX ACLs with NFSv4 ACLs. This does not hold
for an attempt to represent arbitrary NFSv4 ACLs with POSIX ACLs.
Mapping NFSv4 ACLs August 2003 The NFS (Network File System) version 4[rfc3010bis] (NFSv4) specifies
a flavor of Access Control Lists (ACLs) that resembles that of Win-
dows NT's. ACLs are used to specify fine grained control of access
to file system objects. An ACL consists of a number of Access Con-
trol Entries (ACEs), each specify some level of access for an entity;
an entity can be a a user, group or a special entity. The access
level is described using an access mask, which is a bitmask where
each bit describes a level of access, for example read, write and
execute permissions on the file system object.
Table of Contents Mapping NFSv4 ACLs February 2004
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 TTaabbllee ooff CCoonntteennttss
2. NFSv4 ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. POSIX ACLs . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mapping Posix ACLs to NFSv4 ACLs . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . 8
6. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Author's Address . . . . . . . . . . . . . . . . . . . . . 10
8. Copyright . . . . . . . . . . . . . . . . . . . . . . . . 10
Mapping NFSv4 ACLs August 2003 11.. IInnttrroodduuccttiioonn . . . . . . . . . . 3
22.. NNFFSSvv44 AACCLLss . . . . . . . . . . . . . . 3
33.. PPOOSSIIXX AACCLLss . . . . . . . . . . . . . . 4
44.. MMaappppiinngg PPoossiixx AACCLLss
ttoo NNFFSSvv44 AACCLLss . . . . . . . . . . 5
55.. SSeeccuurriittyy
CCoonnssiiddeerraattiioonnss . . . . . . . 7
66.. BBiibblliiooggrraapphhyy . . . . . . . . . . 8
77.. AAcckknnoowwlleeddggmmeennttss . . . . . 9
88.. AAuutthhoorr''ss AAddddrreessss . . . . 10
99.. CCooppyyrriigghhtt . . . . . . . . . . . . . 10
1. Introduction Mapping NFSv4 ACLs February 2004
The NFS (Network File System) version 4 [rfc3530] (NFSv4) specifies a 11.. IInnttrroodduuccttiioonn
flavor of Access Control Lists (ACLs) that resembles that of Windows
NT's. ACLs are used to specify fine grained control of access to
file system objects. An ACL consists of a number of Access Control
Entries (ACEs), each specify some level of access for an entity; an
entity can be a a user, group or a special entity. The access level
is described using an access mask, which is a bitmask where each bit
describes a level of access, for example read, write and execute
permissions on the file system object. The POSIX Draft Standard
17[posixacl] proposes a simpler, more limited ACL model.
Due to the difference in syntax, semantics and extensiveness, it is The NFS (Network File System) version 4 [rfc3010bis] (NFSv4) speci-
only feasible to correctly represent POSIX ACLs using NFSv4 ACLs, and fies a flavor of Access Control Lists (ACLs) that resembles that of
not the other way around. Thus, we provide such a mapping for use in Windows NT's. ACLs are used to specify fine grained control of
systems that implement NFSv4, already have POSIX Draft Standard ACL access to file system objects. An ACL consists of a number of Access
support and wish to continue to use this interface with NFSv4 and Control Entries (ACEs), each specifying some level of access for an
interoperate with other such systems. A client may also use the entity; an entity can be a a user, group or a special entity. The
mapping for storing, retrieving and interpreting ACLs on an NFSv4 access level is described using an access mask, which is a bitmask
server that supports the storage, retrieval and interpretation of where each bit describes a level of access, for example read, write
arbitrary NFSv4 ACLs. and execute permissions on the file system object.
2. NFSv4 ACLs 22.. NNFFSSvv44 AACCLLss
NFSv4 ACLs are rich in nature and expands upon the traditional idea NFSv4 ACLs are rich in nature and expand upon the traditional idea of
of ACLs. An NFSv4 ACE can be of type ALLOW, DENY, LOG or ALARM; each ACLs. An NFSv4 ACE can be of type ALLOW, DENY, LOG or ALARM; each
specifies a different action to take should the ACE match a current specifies a different action to take should the ACE match a current
request. NFSv4 ACLs also have a rich set of access types that request. NFSv4 ACLs also have a rich set of access types that com-
complement the traditional types. These include appending data to plements the traditional types. These include appending data to the
the file system object, deleting children of the file system object file object, deleting children of the file object, deleting the file
and deleting the file system object, etc [rfc3530]. object, etc [rfc3010bis].
NFSv4 ACLs are interpreted in a straightforward manner. NFSv4 ACLs are interpreted in a straightforward manner.
1) Walk through the list of ACEs from the ACL in order 1) Walk through the list of ACEs from the ACL in order
2) If the "who" (entity) field in the ACE does not match that of 2) If the "who" (entity) field in the ACE does not match that of the
the requester, the particular ACE is not processed. requester, the particular ACE is not processed.
3) Process all ACEs until all the bits in the requested access mask 3) Process all ACEs until all the bits in the requested access mask
have been ALLOWed; that is, the bits have entries in matching have been ALLOWed; once a particular bit has been ALLOWed by an
ALLOW ACEs that are not flagged ACE4_INHERIT_ONLY_ACE. Once a ACE, it is no longer considered in further processing.
particular bit has been ALLOWed by an ACE, it is no longer
considered in further processing.
4) If a particular access is DENYed (while that bit is still under 4) If a particular access is DENYed (while that bit is still under
Mapping NFSv4 ACLs August 2003
consideration), the request is denied. consideration), the request is denied.
5) If all bits have been ALLOWed, the access is granted, otherwise 5) If all bits have been ALLOWed, the access is granted, or else
the access is denied behavior is undefined.
NFSv4 ACLs also specify a number of special entities such as OWNER, NFSv4 ACLs also specify a number of special entities such as OWNER,
GROUP and EVERYONE. These refer to the traditional UNIX permissions. GROUP, and EVERYONE. These refer to the traditional UNIX mode bits.
Others include DIALUP, BATCH and AUTHENTICATED, which have Others include DIALUP, BATCH, and AUTHENTICATED, which have special-
specialized uses. ized uses.
Mapping NFSv4 ACLs February 2004
Additionally the NFSv4 ACLs specify a number of flags that can be Additionally the NFSv4 ACLs specify a number of flags that can be
applied to individual ACEs. These include a specification of how an applied to an ACL. These include a specification on how an ACL on a
ACE on a directory may be propagated to newly created files or directory may be propagated to newly created files or directories
directories inside of said directory. inside of said directory.
The granularity of access control provided by NFSv4 ACLs is well It is clear that the granularity of access control that NFSv4 ACLs
beyond that provided by standard UNIX file system permissions. specify is well beyond the standard UNIX capability of expressing
file system object permissions.
3. POSIX ACLs 33.. PPOOSSIIXX AACCLLss
"POSIX ACLs" refer to POSIX 1003.1e/1003.2c Draft Standard 17 POSIX ACLs refer to POSIX 1003.1e/1003.2c Draft Standard 17 [posix-
[posixacl]. It was meant to specify a POSIX standard for ACLs, but acl], which was meant to specify a POSIX standard for ACLs, but
unfortunately never materialized. However, many systems still use unfortunately never materialized. However, many systems still use
it, in forms of its latest and earlier drafts. it, both in the form of it's latest draft as well as earlier drafts.
POSIX ACLs are simpler than its NFSv4 equivalent. Each ACE an has an POSIX ACLs are simpler than their NFSv4 equivalents. Each ACE an has
entity and the traditional UNIX mode bits that are assigned to the an entity and the traditional UNIX mode bits that are assigned to the
particular entity. The entity may be an arbitrary UID or GID or one particular entity. The entity may be an arbitrary UID or GID or one
of a few special entities, the most notable of which is the ACL_MASK of a few special entities, the most notable of which is the ACL_MASK
entity. POSIX ACLs are also interepreted differently than their entity. POSIX ACLs are also interepreted differently than their
NFSv4 equivalents. NFSv4 equivalents.
POSIX ACLs are interpreted as follows: POSIX ACLs are interpreted as follows:
1) Process the ACL_USER_OBJ (equivalent to UNIX file owner) ACE 1) Process the ACL_USER_OBJ (equivalent to UNIX file owner) ACE
first; if the UID of the requester does not match that of the first; if the UID of the requester does not match that of the
ACL_USER_OBJ, then the ACE is ignored. Otherwise, the request ACL_USER_OBJ, then the ACE is ignored. Otherwise, if the
is granted if and only if the request access mask is allowed by requester's access mask is allowed by the access mask of the ACE,
the access mask of the ACE. the request is granted, else the request is denied.
2) Process all of the ACL_USER ACEs; the entity of these ACEs
specifies a user on the system. If the UID of the requester
does not match that of the ACE, then the ACE is ignored.
Otherwise, the request is granted if and only if the request
access mask is allowed by the access mask of the ACE.
Mapping NFSv4 ACLs August 2003 2) Process all of the ACL_USER ACEs; the entity of these ACEs specify
a user on the system. If the UID of the requester does not match
that of the ACE, then the ACE is ignored. Otherwise, if the
requester's access mask is allowed by the access mask of the ACE,
the request is granted, else the request is denied.
3) Process the ACL_GROUP_OBJ ACE and all of the ACL_GROUP ACEs; the 3) Process the ACL_GROUP_OBJ ACE and all of the ACL_GROUP ACEs; the
entity of each ACE specify a group on the system. If none of entity of these ACEs specify a group on the system. If none of
the GIDs of the requester match the entity of the current ACE, the GIDs of the requester match the current ACE, the particular
the particular ACE is ignored. For any matching ACE, if the the ACE is ignored. For any matching ACE, if the the requester's
requester's access mask is allowed by the ACEs access mask, then access mask is allowed by the ACEs access mask, then access is
access is permitted. If there are matching ACEs, but none allow permitted. If there are matching ACEs, but none allow access,
access, then access is denied. then access is denied.
Mapping NFSv4 ACLs February 2004
4) If the requester's access mask is allowed by the ACL_OTHER ACE, 4) If the requester's access mask is allowed by the ACL_OTHER ACE,
then grant access. then grant access.
5) Deny access. 5) Deny access.
Steps (2) and (3) have an additional restriction; in addition to Steps (2) and (3) have an additional criteria; in addition to check-
checking whether the requested access mask is allowed by the access ing whether the requested access mask is allowed by the access mask
mask in the ACE, the requested bits also have to be in the access in the ACE, the requested bits also have to be in the access mask of
mask of the special ACE with the ACL_MASK entity. This allows file the special ACE with the ACL_MASK entity. This allows file owners to
owners to specify a maximum level of access allowed by any other user specify a maximum level of access allowed by any other user or group
or group that has any access to the file system object. that has any access to the file system object.
In addition to a regular POSIX ACL, a directory in the file system In addition to a regular POSIX ACL, a directory in the file system
may also have associated with it a default ACL. A default ACL may also have associated with it a default ACL. This default ACL
governs the ACL a file system object will be assigned initially when governs the ACL a file system object will be assigned initially when
it is created as a child of the particular directory. it is created as a child of the particular directory.
4. Mapping Posix ACLs to NFSv4 ACLs 44.. MMaappppiinngg PPoossiixx AACCLLss ttoo NNFFSSvv44 AACCLLss
Given the difference in both extensiveness and interpretation of Given the difference in both extensiveness and interpretation of
POSIX and NFSv4 ACLs, conversion of arbitrary NFSv4 ACLs to POSIX POSIX and NFSv4 ACLs, any conversion between the two is difficult.
ACLs is infeasible. However, POSIX ACLs are a subset of NFSv4 ACLs. However, POSIX ACLs are a subset of NFSv4 ACLs. Any POSIX ACL can be
Any POSIX ACL can be emulated with an NFSv4 ACL. emulated with an NFSv4 ACL using the following mapping.
The difference in the format of POSIX ACEs and NFSv4 ACEs can be
compensated for by a direct mapping.
The ACE entity is translated as follows. The non-special entity in The ACE entities are translated as follows. The non-special entities
form of UIDs and GIDs is translated to equivalent strings (a system in form of UIDs and GIDs is translated to equivalent strings (a sys-
dependent process, typically done by lookups to /etc/passwd in UNIX). tem dependent process, typically done by lookups to /etc/passwd in
The POSIX ACL_USER_OBJ entity is translated to the "OWNER" NFSv4 UNIX). The POSIX ACL_USER_OBJ entity is translated to the "OWNER"
entity. Similary, the POSIX ACL_GROUP_OBJ is translated to the NFSv4 entity. Similary, the POSIX ACL_GROUP_OBJ is translated to the
"GROUP" NFSv4 entity. The ACL_OTHER entity is translated to the "GROUP" NFSv4 entity. The ACL_OTHER entity is translated to the
"EVERYONE" NFSv4 entity. "EVERYONE" NFSv4 entity.
The access mask is translated as follows. The read bit of the POSIX The ACE access mask is translated as follows. The read bit of the
POSIX access mask is translated to the logical OR of the
ACE4_READ_DATA and ACE4_READ_NAMED_ATTRS NFSv4 access mask fields.
The write bit of the POSIX access mask is translated to the logical
OR of the ACE4_WRITE_DATA, ACE4_WRITE_NAMED_ATTRIBUTES and
ACE4_APPEND_DATA NFSv4 access mask fields. The execute bit of the
POSIX access mask is translated into the ACE4_EXECUTE and
ACE4_READ_DATA NFSv4 acess mask fields. Note that NFSv4 defines
ACE4_READ_DATA, ACE4_WRITE_DATA, and ACE4_APPEND_DATA to be equal to
ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY,
respectively, so this translation makes sense for directories as
well. However, on directories the ACE4_DELETE_CHILD field must be
included in the translation of the POSIX write bit.
Mapping NFSv4 ACLs August 2003 Mapping NFSv4 ACLs February 2004
access mask is translated to the "ACE4_GENERIC_READ" NFSv4 access In addition to the above, the OWNER entity must always be given
mask field. The write bit of the POSIX access mask is translated to ACE4_WRITE_ACL and ACE4_WRITE_ATTRIBUTES, and all entities must be
"ACE4_GENERIC_WRITE" NFSv4 access mask field. the execute bit of the given ACE4_READ_ACL and ACE4_READ_ATTRIBUTES.
POSIX access mask is translated into the "ACE4_GENERIC_EXECUTE" NFSv4
access mask field. Defined in [rfc3530], "ACE4_GENERIC_READ" is a
logical OR of "ACE4_SYNCHRONIZE," "ACE4_READ_ACL,"
"ACE4_READ_ATTRIBUTES," "ACE4_READ_DATA" and "ACE4_LIST_DIRECTORY."
"ACE4_GENERIC_WRITE" is a logical OR of "ACE4_SYNCHRONIZE,"
"ACE4_READ_ACL," "ACE4_WRITE_ACL," "ACE4_WRITE_ATTRIBUTES,"
"ACE4_WRITE_DATA," "ACE4_ADD_FILE," "ACE4_APPEND_DATA" and
"ACE4_ADD_SUBDIRECTORY." Finally, "ACE4_GENERIC_EXECUTE" is a
logical OR of "ACE4_SYNCHRONIZE," "ACE4_READ_ACL,"
"ACE4_READ_ATTRIBUTES" and "ACE4_EXECUTE." These were chosen to
represent the true meaning of the UNIX mode which are used by POSIX
ACLs.
The ACE flag field also has a simple translation. If the file system The ACE flag field also has a simple translation. If the file system
object is a directory, and the POSIX ACE belongs to a default ACL, object is a directory, and the POSIX ACE belongs to a default ACL,
the "ACE4_INHERIT_ONLY_ACE" flag is set in the NFSv4 ACE. If the the "ACE4_INHERIT_ONLY_ACE" flag is set in the NFSv4 ACE. If the
entity in the POSIX ACE refers to a group, the entity in the POSIX ACE refers to a group, the "ACE4_IDENTI-
"ACE4_IDENTIFIER_GROUP" flag is set in the NFSv4 ACE. FIER_GROUP" flag is set in the NFSv4 ACE.
The POSIX ACL_USER_OBJ ACE is also always given the permission bits
"ACE4_READ_ACL" and "ACE4_WRITE_ACL."
Completing the mapping reduces to being able to emulate an ACL_MASK Completing the mapping reduces to being able to emulate an ACL_MASK
and compensate for the difference in interpretation between to two and compensate for the difference in interpretation between two ACL
ACL implementations. implementations.
The difference in interpretation of the two ACL types call for a The difference in interpretation of the two ACL types call for a
translation scheme. The scheme follows: translation scheme. The scheme follows:
Every user ACE in the POSIX ACL maps into 2 NFSv4 ACEs; one ALLOW ACE Every user ACE in the POSIX ACL maps into 2 NFSv4 ACEs; one ALLOW ACE
which is translated as specified by the above scheme, then a which is translated as specified by the above scheme, then a comple-
complementing DENY ACE which is also translated as specified by the menting DENY ACE which is also translated as specified by the above
above scheme, with the exception that the access mask is inverted. scheme, with the exception that the access mask is inverted. Note
The ACL_USER_OBJ ACE is placed first in the list. that the ACL_USER_OBJ ACE is placed first in this list.
Every group ACE in the POSIX ACL produces a similar pair, but instead Every group ACE in the POSIX ACL produces a similar pair, but instead
of being in sequence, all of the ALLOW ACEs are placed first, of being in sequence, all of the ALLOW ACEs are all in sequence, fol-
followed by all the DENY ACEs. The ACL_GROUP_OBJ ACE is placed first lowed by all the DENY ACEs. The ACL_GROUP_OBJ ACE is placed first in
in the list. both lists.
Lastly, the POSIX ACL_OTHER ACE translates directly into one NFSv4 Lastly, the POSIX ACL_OTHER ACE is translated into a pair of ACEs as
ACE at the end of the group ACEs. This is an allow ACE which is in the user ACE case.
translated as specified by the above scheme.
This translation strategy allows us to emulate POSIX ACL This translation strategy allows us to emulate POSIX ACL interpreta-
interpretation in an NFSv4 ACL. tion in an NFSv4 ACL.
To handle the special POSIX entity ACL_MASK, we slightly modify the To handle the special POSIX entity ACL_MASK, we slightly modify the
Mapping NFSv4 ACLs August 2003
above translation: above translation:
With the exception of the "OWNER," "GROUP," and "EVERYONE" ACEs, With the exception of the "OWNER" and "EVERYONE" ACEs, another ACE is
another ACE is prepended to every ACE. The prepended ACE is a DENY prepended to the ACE. The prepended ACE is a DENY ACE with the same
ACE with the same entity as the following ALLOW ACE, but with a entity as the following ALLOW ACE, but with a permission mask set to
permission mask set to the complement of the POSIX ACL_MASK. the complement of the POSIX ACL_MASK.
This method allows us to preserve the real permission bits of each This method allows us to preserve the real permission bits of each
ACE should the ACL_MASK be changed. ACE should the ACL_MASK be changed.
The fact that POSIX ACLs use separate ACLs for determining access to Mapping NFSv4 ACLs February 2004
the file system object and determining inheritance of the ACL needs
compensation in the translation scheme. Whenever the server receives
a request for an ACL, if the file system object in question is a
directory, the server appends the default ACL to the access ACL. It
is then up to the client to separate the two ACLs and translate them
individually. Similarly, when the client wishes to set an ACL, it
either sends the access and default ACLs individually in separate
requests, or concatenates them. Again the server should separate
default and access ACLs, translating and setting them individually.
The reverse mapping follows from the forward mapping described here.
The forward mapping obeys a very strict template, and the implementer
must ensure that when performing the reverse mapping, the ACL
strictly adheres to this template.
Mapping NFSv4 ACLs August 2003
5. Security Considerations 55.. SSeeccuurriittyy CCoonnssiiddeerraattiioonnss
Since this draft deals with the mapping of Access Control Lists, it Since this draft deals with the mapping of Access Control Lists, it
is deeply involved with security. The body of this document needs to is deeply involved with security. The body of this document needs to
address the issue of mapping ACLs in a way as to not disobey the address the issue of mapping ACLs in a way as to not disobey the
intent of or mislead the user. intent of or mislead the user.
It is therefore important that ACLs that do not match the above Mapping NFSv4 ACLs February 2004
scheme are explicitly rejected. Also, neither optimistic nor
pessimistic translation between POSIX and NFSv4 ACLs should be
carried out. This can potentially lead to unintended granting or
revoking of priveliges.
Mapping NFSv4 ACLs August 2003 66.. BBiibblliiooggrraapphhyy
6. Bibliography [rfc3010bis]
Shepler, S. et. al., "NFS version 4 Protocol", draft-ietf-
nfsv4-rfc3010bis-05.txt, April 2003.
[rfc3530] http://www.ietf.org/internet-drafts/draft-ietf-
Shepler, S. et. al., "NFS version 4 Protocol", nfsv4-rfc3010bis-05.txt
http://www.ietf.org/rfc/rfc3530.txt, April 2003.
[posixacl] [posixacl]
IEEE, "IEEE Draft P1003.1e", October 1997 (last draft). IEEE, "IEEE Draft P1003.1e", October 1997 (last draft).
http://wt.xpilot.org/publications/posix.1e/download.html http://wt.xpilot.org/publications/posix.1e/download.html
Mapping NFSv4 ACLs August 2003 Mapping NFSv4 ACLs February 2004
7. Author's Address 77.. AAcckknnoowwlleeddggmmeennttss
The author would like to thank and acknowledge Bruce Fields for his
careful scrutiny and excellent comments and suggestions.
Mapping NFSv4 ACLs February 2004
88.. AAuutthhoorr''ss AAddddrreessss
Address comments related to this memorandum to: Address comments related to this memorandum to:
marius@umich.edu marius@umich.edu
Marius Aamodt Eriksen Marius Aamodt Eriksen
University of Michigan / CITI University of Michigan / CITI
535 West William 535 West William
Ann Arbor, Michigan Ann Arbor, Michigan
E-mail: marius@umich.edu E-mail: marius@umich.edu
8. Copyright 99.. CCooppyyrriigghhtt
Copyright (C) The Internet Society (2002, 2003). All Rights Copyright (C) The Internet Society (2002-2004). All Rights Reserved.
Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this doc-
document itself may not be modified in any way, such as by removing ument itself may not be modified in any way, such as by removing the
the copyright notice or references to the Internet Society or other copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of develop-
developing Internet standards in which case the procedures for ing Internet standards in which case the procedures for copyrights
copyrights defined in the Internet Standards process must be defined in the Internet Standards process must be followed, or as
followed, or as required to translate it into languages other than required to translate it into languages other than English.
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/