draft-ietf-nfsv4-versioning-04.txt   draft-ietf-nfsv4-versioning-05.txt 
es
NFSv4 D. Noveck NFSv4 D. Noveck
Internet-Draft HPE Internet-Draft HPE
Updates: 5661 (if approved) June 2, 2016 Updates: 5661 (if approved) July 28, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: December 4, 2016 Expires: January 29, 2017
NFSv4 Version Management NFSv4 Version Management
draft-ietf-nfsv4-versioning-04 draft-ietf-nfsv4-versioning-05
Abstract Abstract
This document describes the management of versioning within the NFSv4 This document describes the management of versioning within the NFSv4
family of protocols. It covers the creation of minor versions, the family of protocols. It covers the creation of minor versions, the
addition of optional features to existing minor versions, and the addition of optional features to existing minor versions, and the
correction of flaws in features already published as Proposed correction of flaws in features already published as Proposed
Standards. The rules relating to the construction of minor versions Standards. The rules relating to the construction of minor versions
and the interaction of minor version implementations that appear in and the interaction of minor version implementations that appear in
this document supersede the minor versioning rules in RFC5661. this document supersede the minor versioning rules in RFC5661.
skipping to change at page 1, line 37 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2016. This Internet-Draft will expire on January 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
3. Consolidation of Version Management Rules . . . . . . . . . . 9 3. Consolidation of Version Management Rules . . . . . . . . . . 9
4. XDR Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. XDR Considerations . . . . . . . . . . . . . . . . . . . . . 11
4.1. XDR Extension . . . . . . . . . . . . . . . . . . . . . . 11 4.1. XDR Extension . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. XDR Extension in General . . . . . . . . . . . . . . 11 4.1.1. XDR Extension in General . . . . . . . . . . . . . . 11
4.1.2. Particulars of XDR Extension within NFSv4 . . . . . . 12 4.1.2. Particulars of XDR Extension within NFSv4 . . . . . . 12
4.1.3. Rules for XDR Extension within NFSv4 . . . . . . . . 13 4.1.3. Rules for XDR Extension within NFSv4 . . . . . . . . 13
4.2. Handling of Protocol Elements . . . . . . . . . . . . . . 13 4.2. Handling of Protocol Elements . . . . . . . . . . . . . . 13
4.3. Organization of Protocol Elements . . . . . . . . . . . . 15 4.3. Organization of Protocol Elements . . . . . . . . . . . . 15
4.4. Inter-version Interoperability . . . . . . . . . . . . . 15 4.4. Inter-version Interoperability . . . . . . . . . . . . . 15
4.4.1. Requirements for Knowledge of Protocol Elements . . . 15 4.4.1. Requirements for Knowledge of Protocol Elements . . . 15
4.4.2. Establishing Interoperability . . . . . . . . . . . . 16 4.4.2. Establishing Interoperability . . . . . . . . . . . . 17
4.4.3. Determining Knowledge of Protocol Elements . . . . . 18 4.4.3. Determining Knowledge of Protocol Elements . . . . . 18
4.4.4. Interoperability Between Version Groups . . . . . . . 19 4.4.4. Interoperability Between Version Groups . . . . . . . 19
5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 19 5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 19
5.1. Non-XDR Protocol Changes . . . . . . . . . . . . . . . . 19 5.1. Non-XDR Protocol Changes . . . . . . . . . . . . . . . . 20
5.1.1. Field Interpretation and Use . . . . . . . . . . . . 20 5.1.1. Field Interpretation and Use . . . . . . . . . . . . 20
5.1.2. Behavioral Changes . . . . . . . . . . . . . . . . . 21 5.1.2. Behavioral Changes . . . . . . . . . . . . . . . . . 21
5.1.3. Rules for non-XDR changes . . . . . . . . . . . . . . 21 5.1.3. Rules for non-XDR changes . . . . . . . . . . . . . . 22
5.2. Specification of Associated Protocols . . . . . . . . . . 22 5.2. Specification of Associated Protocols . . . . . . . . . . 22
5.2.1. Associated Protocols via pNFS Mapping Types . . . . . 23 5.2.1. Associated Protocols via pNFS Mapping Types . . . . . 23
5.2.2. Additional Forms of Associated Protocols . . . . . . 23 5.2.2. Additional Forms of Associated Protocols . . . . . . 23
6. NFSv4 Protocol Features . . . . . . . . . . . . . . . . . . . 24 6. NFSv4 Protocol Features . . . . . . . . . . . . . . . . . . . 24
6.1. Previous Uses of the Feature Concept . . . . . . . . . . 25 6.1. Previous Uses of the Feature Concept . . . . . . . . . . 25
6.2. Rules for Protocol Feature Construction . . . . . . . . . 26 6.2. Rules for Protocol Feature Construction . . . . . . . . . 26
6.3. Statuses of Features . . . . . . . . . . . . . . . . . . 26 6.3. Statuses of Features . . . . . . . . . . . . . . . . . . 26
6.4. Statuses of Protocol Elements Within Features . . . . . . 27 6.4. Statuses of Protocol Elements Within Features . . . . . . 27
6.5. Determining Protocol Element Support . . . . . . . . . . 29 6.5. Determining Protocol Element Support . . . . . . . . . . 29
6.6. Feature Discovery . . . . . . . . . . . . . . . . . . . . 30 6.6. Feature Discovery . . . . . . . . . . . . . . . . . . . . 30
skipping to change at page 5, line 45 skipping to change at page 5, line 45
2. Terminology 2. Terminology
A basic familiarity with NFSv4 terminology is assumed in this A basic familiarity with NFSv4 terminology is assumed in this
document and the reader is pointed to [RFC7530]. document and the reader is pointed to [RFC7530].
In this document, the term "version" is not limited to minor In this document, the term "version" is not limited to minor
versions. When minor versions are meant, the term "minor version" is versions. When minor versions are meant, the term "minor version" is
used explicitly. For more discussion of this and related terms, see used explicitly. For more discussion of this and related terms, see
Section 2.3 Section 2.3
In this document, the word "feature" is used , except in the case of In this document, the word "feature" is used, except in the case of
quotations, to denote a key structuring concept. By organizing quotations, to denote a key structuring concept. By organizing
changes into features, defining RFCs can clearly specify what changes into features, defining RFCs can clearly specify what
protocol elements a server must be able to recognize and what protocol elements a server must be able to recognize and what
protocol elements a server must support. See Section 6 for more protocol elements a server must support. See Section 6 for details
which allows the defining RFCs to clearly specify what protocol about how features are specified and how the structuring information
elements must be supported together by the server and when a given provided is used.
server must be able to correctly interpret the corresponding
associated protocol constructs. See Section 6 for more details.
A feature contains one or more "feature elements". Often, at least A feature contains one or more "feature elements". Often, at least
one feature element will be a protocol extension that can help a one feature element will be a protocol extension that can help a
sender determine whether the receiver supports a given feature. See sender determine whether the receiver supports a given feature. See
Section 4.1.3 for more details. A feature element may also be one of Section 4.1.3 for more details. A feature element may also be one of
a set of other types of protocol change as described in Section 5. a set of other types of protocol change as described in Section 5.
A "feature package" is a set of features that are defined together, A "feature package" is a set of features that are defined together,
either as part of a minor version or as part of the same protocol either as part of a minor version or as part of the same protocol
extension. extension.
skipping to change at page 8, line 47 skipping to change at page 8, line 43
protocol defined by the minor version specification document, when protocol defined by the minor version specification document, when
combined with any subset (not necessarily proper) of the feature combined with any subset (not necessarily proper) of the feature
specification documents, is a valid NFSv4 version variant which is specification documents, is a valid NFSv4 version variant which is
part of the minor version in question. part of the minor version in question.
o When there are protocol corrections published which update a given o When there are protocol corrections published which update a given
minor version, each set of published updates, up to the date of minor version, each set of published updates, up to the date of
publication of the update, is a valid NFSv4 version variant which publication of the update, is a valid NFSv4 version variant which
is part of the minor version in question. is part of the minor version in question.
Whether the above situations arise depend on the need for protocol
and whether extensions are allowed within a particular minor version.
Protocol corrections are always allowed although it is hoped that
they will be rare.
Whether extensions are allowed depends on whether the minor version
in question is specified as an extensible one. For a description of
rules regarding minor version extensibility, see Section 7.4.
Because of the above, there can be multiple version variants that are Because of the above, there can be multiple version variants that are
part of a given minor version. Two of these are worthy of special part of a given minor version. Two of these are worthy of special
terms: terms:
o The term "base minor version" denotes the version variant that o The term "base minor version" denotes the version variant that
corresponds to the minor version as originally defined, including corresponds to the minor version as originally defined, including
all protocol elements specified in the minor version definition all protocol elements specified in the minor version definition
document but not incorporating any extensions or protocol document but not incorporating any extensions or protocol
corrections published subsequently. corrections published subsequently.
o At any given time, the term "current minor version" denotes the o At any given time, the term "current minor version" denotes the
minor version variant including all extensions of and corrections minor version variant including all extensions of and corrections
to the minor version made by standard-track documents published to the minor version made by standard-track documents published
subsequently. subsequently.
Each version variant which is part of a given minor version is a Each version variant which is part of a given minor version is a
subset of the current minor version and a superset of the base minor subset of the current minor version and a superset of the base minor
version. When the term "minor version" is used without either of version. When the term "minor version" is used without either of
these qualifiers, it should refer to something which is true of all these qualifiers, it should refer to something which is true of all
variants within that minor version. For example, one may refer the variants within that minor version. For example, one may refer to
set of REQUIRED features in a given minor version since it is the the set of REQUIRED features in a given minor version since it is the
same for all variants within the minor version. same for all variants within the minor version.
Each client and server which implements a specific minor version will Each client and server which implements a specific minor version will
implement some particular variant of that minor version. Each of implement some particular variant of that minor version. Each of
these will be a superset of the appropriate base minor version. these will be a superset of the appropriate base minor version.
A minor version group is defined as a successive set of minor A minor version group is defined as a successive set of minor
versions having exactly the same set of REQUIRED and mandatory to not versions having exactly the same set of REQUIRED and mandatory to not
implement protocol elements. The union of the sets of variants for implement protocol elements. The union of the sets of variants for
all these minor versions provides a high degree of inter-variant all these minor versions provides a high degree of inter-variant
skipping to change at page 11, line 6 skipping to change at page 11, line 14
o Otherwise, any conflict between the version management rules in o Otherwise, any conflict between the version management rules in
this document and those in minor version specification RFC's are this document and those in minor version specification RFC's are
to be resolved based on the treatment in this document. In to be resolved based on the treatment in this document. In
particular, corrections may be made as specified in Section 9 for particular, corrections may be made as specified in Section 9 for
all previously specified minor versions and the extensibility of all previously specified minor versions and the extensibility of
previously specified minor versions is to be handled in accord previously specified minor versions is to be handled in accord
with Section 7.1. with Section 7.1.
Future minor version specification documents should avoid specifying Future minor version specification documents should avoid specifying
minor versioning rules and reference this document in connection with minor versioning rules. Instead, this document should be referenced
rules for NFSv4 version management. in connection with rules for NFSv4 version management.
4. XDR Considerations 4. XDR Considerations
As an extensible XDR-based protocol, NFSv4 has to ensure interversion As an extensible XDR-based protocol, NFSv4 has to ensure interversion
compatibility, in situations in which the client and server use compatibility, in situations in which the client and server use
different XDR descriptions. For example, the client may implement different XDR descriptions. For example, the client may implement
different variants of the same minor version or different variants different variants of the same minor version or different variants
that are part of the same minor version group. The XDR extension that are part of the same minor version group. The XDR extension
paradigm, discussed in Section 4.1, assures that these descriptions paradigm, discussed in Section 4.1, assures that these descriptions
are compatible, with clients and servers able to determine and use are compatible, with clients and servers able to determine and use
skipping to change at page 12, line 13 skipping to change at page 12, line 20
structure/interpretation using the extended definition. structure/interpretation using the extended definition.
o Each message within the set of messages described as valid by the o Each message within the set of messages described as valid by the
extended definition but not the base definition must be extended definition but not the base definition must be
recognized, using the base definition, as part of an unsupported recognized, using the base definition, as part of an unsupported
extension. extension.
In general, an extension of a given XDR description consists of any In general, an extension of a given XDR description consists of any
set of the following changes: set of the following changes:
o Addition of previously unspecified RPC operation codes. o Addition of previously unspecified RPC procedures.
o Addition of new, previously unused, values to existing enums. o Addition of new, previously unused, values to existing enums.
o Addition of previously unassigned bit values to a flag word. o Addition of previously unassigned bit values to a flag word.
o Addition of new cases to existing switches, provided that the o Addition of new cases to existing switches, provided that the
existing switch did not contain a default case. existing switch did not contain a default case.
However, none of the following may happen: However, none of the following may happen:
o Deletion of existing RPC operations, enum values, flag bit values o Deletion of existing RPC procedures, enum values, flag bit values
and switch cases. Note that changes may be made to define use of and switch cases. Note that changes may be made to define use of
any of these as causing an error, as long as the XDR is any of these as causing an error, as long as the XDR is
unaffected. unaffected.
o Similarly, none of these items may be reused for a new purpose. o Similarly, none of these items may be reused for a new purpose.
o Any change to the XDR-defined structure of existing requests or o Any change to the XDR-defined structure of existing requests or
replies other than those listed above. replies other than those listed above.
4.1.2. Particulars of XDR Extension within NFSv4 4.1.2. Particulars of XDR Extension within NFSv4
There are issues, particular to NFSv4, that affect the definition of There are issues, particular to NFSv4, that affect the definition of
a valid XDR extension within NFSv4. a valid XDR extension within NFSv4.
o Because NFSv4 has been structured around compound requests and o Because NFSv4 has been structured around compound requests and
callbacks, addition of previously unspecified RPC operation codes callbacks, addition of previously unspecified RPC procedures is
is not allowed. not allowed.
o Although they fit under the general category of enumerations, o Although they fit under the general category of enumerations,
operation codes (including those for callbacks) are so central to operation codes (including those for callbacks) are so central to
the structure of NFSv4, that they merit special treatment. the structure of NFSv4, that they merit special treatment.
o The fact that attribute value sets are represented within NFSv4 by o The fact that attribute value sets are represented within NFSv4 by
nominally opaque arrays calls for special handling. nominally opaque arrays calls for special handling.
4.1.3. Rules for XDR Extension within NFSv4 4.1.3. Rules for XDR Extension within NFSv4
skipping to change at page 13, line 27 skipping to change at page 13, line 30
o Addition of previously unassigned bit values to a flag word. o Addition of previously unassigned bit values to a flag word.
o Addition of new cases to existing switches, provided that the o Addition of new cases to existing switches, provided that the
existing switch did not contain a default case. existing switch did not contain a default case.
However, none of the following is allowed to happen: However, none of the following is allowed to happen:
o Any change to the structure of existing requests or replies other o Any change to the structure of existing requests or replies other
than those listed above. than those listed above.
o Addition of previously unspecified RPC operation codes, for either o Addition of previously unspecified RPC procedures, for either the
the nfsv4 program or the callback program, is not allowed. nfsv4 program or the callback program, is not allowed.
o Deletion of existing RPC operations, enum values, flag bit values o Deletion of existing RPC procedures, enum values, flag bit values
and switch cases. Note that changes may be made to define use of and switch cases. Note that changes may be made to define use of
any of these as causing an error, as long as the XDR is any of these as causing an error, as long as the XDR is
unaffected. unaffected.
o Similarly, none of these items may be reused for a new purpose. o Similarly, none of these items may be reused for a new purpose.
4.2. Handling of Protocol Elements 4.2. Handling of Protocol Elements
Implementations handle protocol elements in one of three ways. Which Implementations handle protocol elements in one of three ways. Which
of the following ways are valid depends on the status of the protocol of the following ways are valid depends on the status of the protocol
element in the variant being implemented: element in the variant being implemented:
o The protocol element is not a part of definition of the variant in o The protocol element is not a part of definition of the variant in
question and so is "unknown". The responder, when it does not question and so is "unknown". The responder, when it does not
report an RPC XDR decode error. reports an error indicative of report an RPC XDR decode error, reports an error indicative of the
the element not being defined in the XDR such as element not being defined in the XDR such as NFS4ERR_OP_ILLEGAL,
NFS4ERR_OP_ILLEGAL, NFS4ERR_BADXDR, or NFS4ERR_INVAL. See NFS4ERR_BADXDR, or NFS4ERR_INVAL. See Section 4.4.3 for details.
Section 4.4.3 for details.
o The protocol element is a known part of the variant but is not o The protocol element is a known part of the variant but is not
supported by the particular implementation. The responder reports supported by the particular implementation. The responder reports
an error indicative of the element being recognized as one which an error indicative of the element being recognized as one which
is not supported such as NFS4ERR_NOTSUPP, NFS4ERR_UNION_NOTSUPP, is not supported such as NFS4ERR_NOTSUPP, NFS4ERR_UNION_NOTSUPP,
or NFS4ERR_ATTRNOTSUPP. See Section 6.5 for details. or NFS4ERR_ATTRNOTSUPP. See Section 6.5 for details.
o The protocol element is a known part of the variant which is o The protocol element is a known part of the variant which is
supported by the particular implementation. The responder reports supported by the particular implementation. The responder reports
success or an error other than the special ones discussed above. success or an error other than the special ones discussed above.
Which of these are validly returned by the responder depends on the Which of these are validly returned by the responder depends on the
status of the feature element in the minor version specified in the status of the feature element in the minor version specified in the
COMPOUND or CB_COMPOUND. The possibilities which can exist are COMPOUND or CB_COMPOUND. The possibilities which can exist are
listed below. listed below.
o The protocol element is not known in the current variant of minor o The protocol element is not known in the current variant of the
version. In this case all implementations of the minor version minor version. In this case all implementations of the minor
MUST indicate that the protocol element is not known. version MUST indicate that the protocol element is not known.
o The protocol element is specified mandatory to not implement in o The protocol element is specified mandatory to not implement in
the minor version. In this case as well, all implementations of the minor version. In this case as well, all implementations of
the minor version MUST indicate that the protocol element is not the minor version MUST indicate that the protocol element is not
known. known.
o The protocol element is defined as part of the current variant of o The protocol element is defined as part of the current variant of
the minor version but is not part of the corresponding base the minor version but is not part of the corresponding base
variant. In this case, the requester can encounter situations in variant. In this case, the requester can encounter situations in
which the protocol element is either not known to the responder , which the protocol element is either not known to the responder ,
skipping to change at page 14, line 45 skipping to change at page 14, line 49
is supported or is not supported. is supported or is not supported.
o The protocol element is defined as a REQUIRED part of the base o The protocol element is defined as a REQUIRED part of the base
minor version. In this case, the requester can expect the minor version. In this case, the requester can expect the
protocol element to be both known and supported by the responder. protocol element to be both known and supported by the responder.
The listing of possibilities above does not mean that a requester The listing of possibilities above does not mean that a requester
always needs to be prepared for all such possibilities. Often, always needs to be prepared for all such possibilities. Often,
depending on the scope of the feature of which the protocol element depending on the scope of the feature of which the protocol element
is a part, handling of a previous request using the same or related is a part, handling of a previous request using the same or related
protocol elements, will allow the requester to be sure that certain protocol elements will allow the requester to be sure that certain of
of these possibilities cannot occur. these possibilities cannot occur. Section 6.6 discusses this subject
in detail.
Requesters, typically clients, may test for knowledge of or support Requesters, typically clients, may test for knowledge of or support
for protocol elements as part of connection establishment. This may for protocol elements as part of connection establishment. This may
allow the requester to be aware of responder lack of knowledge of or allow the requester to be aware of responder lack of knowledge of or
support for problematic requests before they are actually issued. support for problematic requests before they are actually issued.
4.3. Organization of Protocol Elements 4.3. Organization of Protocol Elements
To enable compatible operation within a version group, all of the To enable compatible operation within a version group, all of the
protocol elements within an NFSv4 minor version are organized as protocol elements within an NFSv4 minor version are organized as
skipping to change at page 15, line 23 skipping to change at page 15, line 28
Section 6 for others) is to regularize and simplify the Section 6 for others) is to regularize and simplify the
determination by the client and server as to what protocol determination by the client and server as to what protocol
elements the other party supports. elements the other party supports.
o Each feature is defined as a member of a feature package, based on o Each feature is defined as a member of a feature package, based on
how it was defined. Features established as part of a minor how it was defined. Features established as part of a minor
version at the same time belong to the same feature package. version at the same time belong to the same feature package.
4.4. Inter-version Interoperability 4.4. Inter-version Interoperability
Because of NFSv4's use of XDR extension, any communicating client and Because of NFSv4's use of XDR extension, there will always be, for
server versions have XDR definitions that are each valid extensions any communicating client and server versions, a version such the
of a third version. Once that version is determined, it may be used client and server versions are each either identical to that common
by both client and server to communicate. Each party can base version or a valid extension of it. Once that base version is
successfully use a subset of protocol elements that are both known determined, it may be used by both client and server to communicate.
and supported by both parties. Each party can successfully use a subset of protocol elements that
are both known and supported by both parties.
4.4.1. Requirements for Knowledge of Protocol Elements 4.4.1. Requirements for Knowledge of Protocol Elements
With regard to requirements for knowledge of protocol elements, the With regard to requirements for knowledge of protocol elements, the
following rules apply. These rules are the result of the use of XDR following rules apply. These rules are the result of the use of the
extension paradigm combined with the way in which extensions are XDR extension paradigm combined with the way in which extensions are
incorporated in existing minor versions (for details of which see incorporated in existing minor versions (for details of which see
Section 7.1). Section 7.1). For information about the rules regarding the
extensibility of minor versions, see Section 7.4.
o Any protocol element defined as part of the base variant of o Any protocol element defined as part of the base variant of a
particular minor version is required to be known by that minor particular minor version is required to be known by that minor
version. This occurs whether the specification happens in the version. This occurs whether the specification happens in the
body of the minor definition document or is in a feature body of the minor definition document or is in a feature
definition document that is made part of the minor version by definition document that is made part of the minor version by
being normatively referenced by the minor version definition being normatively referenced by the minor version definition
document. document.
o Any protocol element required to be known in a given minor version o Any protocol element required to be known in a given minor version
is required to be known in subsequent minor version, unless and is required to be known in subsequent minor versions, unless and
until a minor version has made that protocol element as mandatory until a minor version has made that protocol element as mandatory
to not implement. to not implement.
o When a protocol element is defined as part of an extension to an o When a protocol element is defined as pahttp://conf.meetecho.com/
extensible minor version, it is not required to be known in that presenter/?id=nfsv4rt of an extension to an extensible minor
minor version but is required to be known by the next minor version, it is not required to be known in that minor version but
version. In the earlier minor version, it might not be defined in is required to be known by the next minor version. In the earlier
the XDR definition document for that minor, while in the later minor version, it might not be defined in the XDR definition
version it needs to be defined in the XDR definition document. In document for that minor, while in the later minor version it needs
either case, if it is defined, it might or might not be supported. to be defined in the XDR definition document. In either case, if
it is defined, it might or might not be supported.
o When knowledge of protocol elements is optional in a given minor o When knowledge of protocol elements is optional in a given minor
version, the responder's knowledge of such optional elements must version, the responder's knowledge of such optional elements must
obey the rule that if one such element is known, then all the obey the rule that if one such element is known, then all the
protocol elements defined in the same minor version definition protocol elements defined in the same minor version definition
document must be known as well. document must be known as well.
For many minor versions, all existing protocol elements, are required For many minor versions, all existing protocol elements are required
to be known by both the client and the server, and so requesters do to be known by both the client and the server, and so requesters do
not have to test for the presence or absence of knowledge regarding not have to test for the presence or absence of knowledge regarding
protocol elements for which knowledge might be optional. This is the protocol elements for which knowledge might be optional. This is the
case if there has been no extension for the minor version in case if there has been no extension for the minor version in
question. Extensions can be added to extensible minor versions as question. Extensions can be added to extensible minor versions as
described in Section 7.1 and can be used to correct protocol flaws as described in Section 7.1 and can be used to correct protocol flaws as
described in Section 9. described in Section 9.
Requesters can ascertain the knowledge of the responder in two ways: Requesters can ascertain the knowledge of the responder in two ways:
skipping to change at page 16, line 41 skipping to change at page 16, line 50
o By receiving a request from the responder, acting in the role of o By receiving a request from the responder, acting in the role of
requester. For example, a client may issue a request enabling the requester. For example, a client may issue a request enabling the
server to infer that it is aware of a corresponding callback. server to infer that it is aware of a corresponding callback.
In making this determination, the requester can rely on two basic In making this determination, the requester can rely on two basic
facts: facts:
o If the responder is aware of a single protocol element within a o If the responder is aware of a single protocol element within a
feature package, it must be aware of all protocol elements within feature package, it must be aware of all protocol elements within
that feature package that feature package.
o If a protocol element is one defined by the minor version o If a protocol element is one defined by the minor version
specified by a request (and not in an extension), or in a previous specified by a request (and not in an extension), or in a previous
minor version, the responder must be aware of it. minor version, the responder must be aware of it.
4.4.2. Establishing Interoperability 4.4.2. Establishing Interoperability
When a client and a server interact, they need to able to take When a client and a server interact, they need to able to take
advantage of the compatibility provided by NFSv4's use of XDR advantage of the compatibility provided by NFSv4's use of XDR
extension. extension.
skipping to change at page 36, line 51 skipping to change at page 36, line 51
cases, making an XDR change, in the form of an extension will be the cases, making an XDR change, in the form of an extension will be the
best way of correcting an issue. See Section 9 for details. best way of correcting an issue. See Section 9 for details.
While making minor versions extensible will decrease the frequency of While making minor versions extensible will decrease the frequency of
new minor versions, it will not eliminate the need for them. new minor versions, it will not eliminate the need for them.
Protocol features that cannot be used as extensions (see Protocol features that cannot be used as extensions (see
Section 8.1.1 require a new minor version. Section 8.1.1 require a new minor version.
In addition, change which involve modifications to the set of In addition, change which involve modifications to the set of
protocol elements which are REQUIRED or mandatory to not implement protocol elements which are REQUIRED or mandatory to not implement
require a new minor version which starts a new minor version group. requires a new minor version which starts a new minor version group.
Changes to the organization of protocol features are treated Changes to the organization of protocol features are treated
similarly, since they have a similar potential to cause interversion similarly, since they have a similar potential to cause interversion
incompatibility. See Section 8.1.2 for details. incompatibility. See Section 8.1.2 for details.
8. Minor Versions 8. Minor Versions
8.1. Creation of New Minor Versions 8.1. Creation of New Minor Versions
It is important to note that this section, in describing situations It is important to note that this section, in describing situations
 End of changes. 30 change blocks. 
54 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/