draft-ietf-nfsv4-versioning-10.txt   draft-ietf-nfsv4-versioning-11.txt 
NFSv4 D. Noveck NFSv4 D. Noveck
Internet-Draft NetApp Internet-Draft NetApp
Updates: 5661, 7862 (if approved) May 25, 2017 Updates: 5661, 7862 (if approved) May 30, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: November 26, 2017 Expires: December 1, 2017
Rules for NFSv4 Extensions and Minor Versions Rules for NFSv4 Extensions and Minor Versions
draft-ietf-nfsv4-versioning-10 draft-ietf-nfsv4-versioning-11
Abstract Abstract
This document describes the rules relating to the extension of the This document describes the rules relating to the extension of the
NFSv4 family of protocols. It covers the creation of minor versions, NFSv4 family of protocols. It covers the creation of minor versions,
the addition of optional features to existing minor versions, and the 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 and this document supersede the minor versioning rules in RFC5661 and
skipping to change at page 1, line 38 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 November 26, 2017. This Internet-Draft will expire on December 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 30 skipping to change at page 2, line 30
4.3. Handling of Protocol Elements by Responders . . . . . . . 9 4.3. Handling of Protocol Elements by Responders . . . . . . . 9
4.4. Inter-version Interoperability . . . . . . . . . . . . . 11 4.4. Inter-version Interoperability . . . . . . . . . . . . . 11
4.4.1. Requirements for Knowledge of Protocol Elements . . . 11 4.4.1. Requirements for Knowledge of Protocol Elements . . . 11
4.4.2. Establishing Interoperability . . . . . . . . . . . . 12 4.4.2. Establishing Interoperability . . . . . . . . . . . . 12
4.4.3. Determining Knowledge of Protocol Elements . . . . . 14 4.4.3. Determining Knowledge of Protocol Elements . . . . . 14
4.5. XDR Overlay . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. XDR Overlay . . . . . . . . . . . . . . . . . . . . . . . 15
5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 15 5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 15
5.1. Field Interpretation and Use . . . . . . . . . . . . . . 15 5.1. Field Interpretation and Use . . . . . . . . . . . . . . 15
5.2. Behavioral Changes . . . . . . . . . . . . . . . . . . . 16 5.2. Behavioral Changes . . . . . . . . . . . . . . . . . . . 16
6. Extending Existing Minor Versions . . . . . . . . . . . . . . 17 6. Extending Existing Minor Versions . . . . . . . . . . . . . . 17
7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 17 7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Creation of New Minor Versions . . . . . . . . . . . . . 17 7.1. Creation of New Minor Versions . . . . . . . . . . . . . 18
8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 18 8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 18
8.1. Minor Version Identifier Transfer Issues . . . . . . . . 18 8.1. Minor Version Identifier Transfer Issues . . . . . . . . 18
8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 19 8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 19
9. Correction of Existing Minor Versions and Features . . . . . 20 9. Correction of Existing Minor Versions and Features . . . . . 20
9.1. XDR Changes to Implement Protocol Corrections . . . . . . 20 9.1. XDR Changes to Implement Protocol Corrections . . . . . . 20
9.2. XDR Corrections to OPTIONAL features . . . . . . . . . . 21 9.2. XDR Corrections to OPTIONAL Features . . . . . . . . . . 21
9.3. XDR Corrections to REQUIRED features . . . . . . . . . . 22 9.3. XDR Corrections to REQUIRED Features . . . . . . . . . . 22
9.4. Addressing XDR Corrections in Later Minor Versions . . . 23 9.4. Addressing XDR Corrections in Later Minor Versions . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
To address the requirement for an NFS protocol that can evolve as the To address the requirement for an NFS protocol that can evolve as the
need arises, the Network File System (NFS) version 4 (NFSv4) protocol need arises, the Network File System (NFS) version 4 (NFSv4) protocol
provides a framework to allow for future changes via the creation of provides a framework to allow for future changes via the creation of
new protocol versions including minor versions and certain forms of new protocol versions including minor versions and certain forms of
skipping to change at page 3, line 38 skipping to change at page 3, line 38
The goal of allowing extensions within the context of a minor version The goal of allowing extensions within the context of a minor version
is to provide more implementation flexibility while preserving is to provide more implementation flexibility while preserving
interoperability on protocol upgrade. As described in Section 4.4, interoperability on protocol upgrade. As described in Section 4.4,
two implementations can each choose a subset of available extensions, two implementations can each choose a subset of available extensions,
with the client able to use the subset of the extensions that it is with the client able to use the subset of the extensions that it is
prepared to use that the server supports as well. Support for this prepared to use that the server supports as well. Support for this
common subset is not affected by the fact that extensions outside common subset is not affected by the fact that extensions outside
this common subset may be supported by the server or potentially used this common subset may be supported by the server or potentially used
by the client. by the client.
The rules in this document supersede previous rules regarding minor
versions. The new rules concerning protocol extension and minor
versions are summarized in Section 3 while rules regarding the
interaction of minor versions appear in Section 8.
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
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.
2.1. Use of Keywords Defined in RFC2119 2.1. Use of Keywords Defined in RFC2119
The keywords defined by [RFC2119] have special meanings which this The keywords defined by [RFC2119] have special meanings which this
document intends to adhere to. However, due to the nature of this document intends to adhere to. However, due to the nature of this
document and some special circumstances, there are some complexities document and some special circumstances, there are some complexities
to take note of: to take note of:
skipping to change at page 6, line 50 skipping to change at page 6, line 47
Rather than a single list of extension rules, as was done in the Rather than a single list of extension rules, as was done in the
minor versioning rules in [RFC5661], this document defines multiple minor versioning rules in [RFC5661], this document defines multiple
sets of rules that deal with the various forms of protocol change sets of rules that deal with the various forms of protocol change
provided for in the NFSv4 extension framework. provided for in the NFSv4 extension framework.
o The kinds of XDR changes that may be made to extend NFSv4 are o The kinds of XDR changes that may be made to extend NFSv4 are
addressed in the rules in Section 4.2. addressed in the rules in Section 4.2.
o Minor version construction, including rules applicable to changes o Minor version construction, including rules applicable to changes
which cannot be made in extensions to existing minor versions are which cannot be made in extensions to existing minor versions are
addressed in Section 7.1 addressed in Section 7.1.
o Minor version interaction rules are discussed in Sections 8.1 and o Minor version interaction rules are discussed in Sections 8.1 and
8.2. 8.2.
This document supersedes minor versioning rules appearing in the This document supersedes minor versioning rules appearing in the
minor version specification RFC's, including those in [RFC5661] and minor version specification RFC's, including those in [RFC5661] and
also the modification to those rules mentioned in [RFC7862]. As a also the modification to those rules mentioned in [RFC7862]. As a
result, potential conflicts among documents should be addressed as result, potential conflicts among documents should be addressed as
follows: follows:
o The specification of the actual protocols for minor versions o The specification of the actual protocols for minor versions
previously published as Proposed Standards take precedence over previously published as Proposed Standards take precedence over
minor versioning rules in either this document or in the minor minor versioning rules in either this document or in the minor
version specification RFC's. In other words, if the transition version specification RFC's. In other words, if the transition
from version A to version B violates a minor versioning rule, the from version A to version B violates a minor versioning rule, the
version B protocol stays as it is. version B protocol stays as it is.
o Since the minor versioning rules #11 and #13 that appear in o Since minor versioning rules #11 and #13 from [RFC5661] deal with
Section 2.7 of [RFC5661] deal with the interactions between the interactions between multiple minor versions, the situation is
multiple minor versions, the situation is more complicated. See more complicated. See Section 8 for a discussion of these issues,
Section 8 below for a discussion of these issues, including how including how potential conflicts between rules are to be
potential conflicts between rules are to be resolved. resolved.
o Otherwise, any conflict between the extension rules in this o Otherwise, any conflict between the extension rules in this
document and those in minor version specification RFC's are to be document and those in minor version specification RFC's are to be
resolved based on the treatment in this document. In particular, resolved based on the treatment in this document. In particular,
corrections may be made as specified in Section 9 for all corrections may be made as specified in Section 9 for all
previously specified minor versions, and the extensibility of 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 6. with Section 6.
Future minor version specification documents should avoid specifying Future minor version specification documents should avoid specifying
skipping to change at page 12, line 31 skipping to change at page 12, line 31
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.
In this context, the client and server would arrive at a common In this context, the client and server would arrive at a common
variant which the client would uses to send requests which the server variant which the client uses to send requests which the server would
would then accept. The server would use that variant to send then accept. The server would use that variant to send callbacks
callbacks which the client would then accept. This state of affairs which the client would then accept. This state of affairs could
could arise in a number of ways: arise in a number of ways:
o Client and server have been built using XDR variants that belong o Client and server have been built using XDR variants that belong
to the same minor version to the same minor version.
o The client's minor version is lower than that of the server. In o The client's minor version is lower than that of the server. In
this case the server, in accord with Section 8.2, accepts the this case the server, in accord with Section 8.2, accepts the
client's minor version, and acts as if it has no knowledge of client's minor version, and acts as if it has no knowledge of
extensions made in subsequent minor versions. It has knowledge of extensions made in subsequent minor versions. It has knowledge of
protocol elements within the current (i.e. effectively final) protocol elements within the current (i.e. effectively final)
variant of the lower minor version. variant of the lower minor version.
o The client's minor version is higher than that of the server. In o The client's minor version is higher than that of the server. In
this case the client, in accord with Section 8.2, uses a lower this case the client, in accord with Section 8.2, uses a lower
minor version that the server will accept. In this case, the minor version that the server will accept. In this case, the
server has no knowledge of extensions made in subsequent minor server has no knowledge of extensions made in subsequent minor
versions. versions.
There are a number of cases to consider based on the characteristics There are a number of cases to consider based on the characteristics
of the minor version chosen. of the minor version chosen.
o When minor version consists of only a single variant (no extension o When the minor version consists of only a single variant (no
or XDR corrections), the client and the server are using the same extension or XDR corrections), the client and the server are using
XDR description and have knowledge of the same protocol elements. the same XDR description and have knowledge of the same protocol
elements.
o When the minor version consists of multiple variants (i.e. there o When the minor version consists of multiple variants (i.e. there
are one or more XDR extensions or XDR corrections), the client and are one or more XDR extensions or XDR corrections), the client and
the server are using compatible XDR descriptions. The client is the server are using compatible XDR descriptions. The client is
aware of some set of extensions while the server may be aware of a aware of some set of extensions while the server may be aware of a
different set. The client can use the approach described in different set. The client can use the approach described in
Section 4.4.3 to determine which of the extensions it knows about Section 4.4.3 to determine which of the extensions it knows about
are also known by the server. Once this is done, the client and are also known by the server. Once this is done, the client and
server will both be using a common variant. The variants that the server will both be using a common variant. The variants that the
client and the server were built with will both either be client and the server were built with will both either be
skipping to change at page 16, line 44 skipping to change at page 16, line 44
overlay the nominally opaque arrays. Such cases are discussed in overlay the nominally opaque arrays. Such cases are discussed in
Section 4.5. Section 4.5.
5.2. Behavioral Changes 5.2. Behavioral Changes
Changes in the behavior of NFSv4 operations are possible, even if Changes in the behavior of NFSv4 operations are possible, even if
there is no change in the underlying XDR or change to field there is no change in the underlying XDR or change to field
interpretation and use. interpretation and use.
One class of behavioral change involves changes in the set of errors One class of behavioral change involves changes in the set of errors
to be returned in the event of various errors. When the set of valid to be returned when various failure conditions occur. When the set
requests remain the same, and the behavior for each of them remains of valid requests remain the same, and the behavior for each of them
the same, such changes can be implemented with only limited remains the same, such changes can be implemented with only limited
disruption to existing clients. disruption to existing clients.
Many more substantial behavioral changes have occurred in connection Many more substantial behavioral changes have occurred in connection
with the addition of the session concept in NFSv4.1. Even though with the addition of the session concept in NFSv4.1. Even though
there was no change to the XDR for existing operations, many existing there was no change to the XDR for existing operations, many existing
operations and COMPOUNDs consisting only of them became invalid. operations and COMPOUNDs consisting only of them became invalid.
Also, changes were made regarding the required server behavior as to Also, changes were made regarding the required server behavior as to
the interaction of the MODE and ACL attributes. the interaction of the MODE and ACL attributes.
6. Extending Existing Minor Versions 6. Extending Existing Minor Versions
Extensions to the most recently published NFSv4 minor version may be Extensions to the most recently published NFSv4 minor version may be
made by publishing the extension as a Proposed Standard, unless the made by publishing the extension as a Proposed Standard, unless the
minor version in question has been defined as non-extensible. A minor version in question has been defined as non-extensible. A
document need not use the "Updates" header specifying the RFC document need not use the "Updates" header specifying the RFC that
defining the minor version, which remains a valid description of the defines the minor version, which remains a valid description of the
base variant of the minor version in question. base variant of the minor version in question.
In addition to following the rules for XDR extensions in Section 4.2, In addition to following the rules for XDR extensions in Section 4.2,
such extensions must also obey the rules listed below in order to such extensions must also obey the rules listed below in order to
allow interoperability to be established, as described in allow interoperability to be established, as described in
Section 4.4: Section 4.4:
o Additions to the set of callback requests and extensions to the o Additions to the set of callback requests and extensions to the
XDR for existing callback operations can only be made if the XDR for existing callback operations can only be made if the
server can determine, based on the client's actions, that that server can determine, based on the client's actions, that that
skipping to change at page 17, line 44 skipping to change at page 17, line 44
but that is not required. Use of any protocol element defined in but that is not required. Use of any protocol element defined in
the extension can be the basis of the determination, provided that the extension can be the basis of the determination, provided that
the requirements for determining client awareness are clearly the requirements for determining client awareness are clearly
stated. stated.
Corrections to protocol errors (see Section 9) may be accomplished by Corrections to protocol errors (see Section 9) may be accomplished by
publishing an extension, including a compatible XDR change which publishing an extension, including a compatible XDR change which
follows the rules above. Such documents will update the defining follows the rules above. Such documents will update the defining
documents for the minor version to be corrected. documents for the minor version to be corrected.
In some cases extensions will contain elements such as new operations
or previously invalid switch cases. Although it is possible to
determine whether these OPTIONAL elements are supported using the
rules described above, those defining an extension that contains such
elements have the choice of defining a new attribute that indicates
whether the feature is present and supported. Since it is easy to
determine whether a new attribute is supported using the
supported_attrs attribute, this can make it simple and convenient for
clients to determine whether support is present, particularly when a
feature involves support for multiple such elements.
7. Minor Versions 7. Minor Versions
7.1. Creation of New Minor Versions 7.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
that would require new minor versions to be created, does not thereby that would require new minor versions to be created, does not thereby
imply that situations will exist in the future. Judgments regarding imply that situations will exist in the future. Judgments regarding
desirability of future changes will be made by the working group or desirability of future changes will be made by the working group or
its successors and any guidance that can be offered at this point is its successors and any guidance that can be offered at this point is
necessarily quite limited. necessarily quite limited.
skipping to change at page 21, line 23 skipping to change at page 21, line 35
corrections is such that it may result in situations in which corrections is such that it may result in situations in which
different variants of the same minor version may not both support different variants of the same minor version may not both support
the corrected version. See Section 9.3 for details. the corrected version. See Section 9.3 for details.
o In all of the cases above, it is appropriate that the old version o In all of the cases above, it is appropriate that the old version
of the feature be considered obsolescent, with the expectation of the feature be considered obsolescent, with the expectation
that the working group might, in a later minor version, change the that the working group might, in a later minor version, change the
status of the uncorrected version. See Section 9.4 for more status of the uncorrected version. See Section 9.4 for more
detail. detail.
9.2. XDR Corrections to OPTIONAL features 9.2. XDR Corrections to OPTIONAL Features
By defining the corrected and uncorrected version as independent By defining the corrected and uncorrected version as independent
OPTIONAL features, the protocol with the XDR modification can OPTIONAL features, the protocol with the XDR modification can
accommodate clients and servers that support either the corrected or accommodate clients and servers that support either the corrected or
the uncorrected version of the protocol and also clients and servers the uncorrected version of the protocol and also clients and servers
aware of and capable of supporting both alternatives. aware of and capable of supporting both alternatives.
Based on the type of client: Based on the type of client:
o A client that uses only the earlier version of the feature (i.e., o A client that uses only the earlier version of the feature (i.e.,
skipping to change at page 22, line 23 skipping to change at page 22, line 35
support of that particular feature. support of that particular feature.
o A server that supports both the older and newer versions of the o A server that supports both the older and newer versions of the
feature can interoperate with all client variants. feature can interoperate with all client variants.
By using extensions in this manner, the protocol creates a clear path By using extensions in this manner, the protocol creates a clear path
which preserves the functioning of existing clients and servers and which preserves the functioning of existing clients and servers and
allows client and server implementers to adopt the new version of the allows client and server implementers to adopt the new version of the
feature at a reasonable pace. feature at a reasonable pace.
9.3. XDR Corrections to REQUIRED features 9.3. XDR Corrections to REQUIRED Features
Interoperability issues in this case are similar to those for the Interoperability issues in this case are similar to those for the
OPTIONAL case described above (in Section 9.2). However, because the OPTIONAL case described above (in Section 9.2). However, because the
use of the uncorrected version is REQUIRED, servers have to support use of the uncorrected version is REQUIRED, servers have to support
this until there is a minor version change. Nevertheless, there is this until there is a minor version change. Nevertheless, there is
the opportunity for clients and servers to implement the corrected the opportunity for clients and servers to implement the corrected
version, while maintaining necessary interoperability with earlier version, while maintaining necessary interoperability with earlier
implementations. implementations.
The following types of servers can exist: The following types of servers can exist:
skipping to change at page 23, line 29 skipping to change at page 23, line 41
o Clients aware of and prepared to use either version. o Clients aware of and prepared to use either version.
Such clients would be capable of interoperating with all of the Such clients would be capable of interoperating with all of the
types of servers listed above, and could use the corrected version types of servers listed above, and could use the corrected version
with servers that supported it. with servers that supported it.
o Clients aware of both versions while only prepared to use the o Clients aware of both versions while only prepared to use the
newer, corrected, version. newer, corrected, version.
Such clients would only be capable of interoperating with servers Such clients would only be capable of interoperating with servers
that supported the correct version. With other types of server, that supported the corrected version. With other types of
they could determine the absence of appropriate support at an servers, they could determine the absence of appropriate support
early stage and treat the minor version in question as unsupported at an early stage and treat the minor version in question as
by the server. Such clients are only likely to be deployed when unsupported by the server. Such clients are only likely to be
the majority of servers support the corrected version. deployed when the majority of servers support the corrected
version.
9.4. Addressing XDR Corrections in Later Minor Versions 9.4. Addressing XDR Corrections in Later Minor Versions
As described in Sections 9.2 and 9.3, a corrected XDR can be As described in Sections 9.2 and 9.3, a corrected XDR can be
incorporated in an existing minor version and be used, while an incorporated in an existing minor version and be used, while an
existing uncorrected version is still supported. Nevertheless, the existing uncorrected version is still supported. Nevertheless, the
uncorrected version will remain part of the protocol until its status uncorrected version will remain part of the protocol until its status
is changed in a later minor version. is changed in a later minor version.
One possible change that could be made in a later minor version is to One possible change that could be made in a later minor version is to
 End of changes. 21 change blocks. 
41 lines changed or deleted 50 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/